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Voorwoord 


Besturingssystemen vormen een essentieel onderdeel van computersystemen. 
Evenzo vormt een cursus besturingssystemen een essentieel onderdeel van een 
informaticastudie. Dit boek is bedoeld als een leerboek voor een inleidende cur- 
sus besturingssystemen op het niveau van het HBO of vóórkandidaats-college. 
Het geeft een duidelijke beschrijving van de begrippen die aan besturingssystemen 
ten grondslag liggen. 

Dit boek concentreert zich niet op een bepaald besturingssysteem of speci- 
fieke apparatuur. In plaats daarvan worden er basisbegrippen in besproken die 
van toepassing zijn op tal van besturingssystemen. Bij ons ligt de nadruk op 
het oplossen van de problemen die men tegenkomt bij het ontwerpen van een 
besturingssysteem, ongeacht de apparatuur waarop het systeem zal draaien. 


Inhoud van dit boek 
De globale inhoud van het boek is als volgt: 


Inleiding 

Functies van besturingssystemen 
Bestandssystemen 
CVE-werkindeling 
Geheugenbeheer 

Virtueel geheugen 

Werkindeling schijf- en trommelgeheugen 
Impasses 

Parallelle processen 
Parallel-programmering 
Beveiliging 
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pi pi 


xii 


12 Grondbeginselen systeemontwerpen 
13 Gedistribueerde systemen 

14 Het Unix-besturingssysteem 

15 Historisch perspectief 


Wat de vereiste voorkennis betreft, gaan we ervan uit dat de lezer bekend 
is met algemene programmering in de assembleertaal en de organisatie van com- 
puters. We bespreken niet in detail wat de karakteristieke eigenschappen zijn van 
randapparatuur (in- en uitvoerapparatuur), of hoe daarvoor de stuurprogram- 
ma’s (Engels: device drivers) geschreven moeten worden. 

De hoofdstukken 1, 2 en 3 behandelen wat besturingssystemen zijn en wat 
ze doen. In deze hoofdstukken wordt uiteengezet hoe het begrip ’besturingssys- 
teem’ zich heeft ontwikkeld, wat een besturingssysteem gewoonlijk zoal kan, wat 
het doet voor de gebruiker en wat het doet voor de operateur van het computer- 
systeem (de persoon die het computersysteem bedient). We geven daarbij 
beweegredenen, een stukje geschiedenis, alsook verklaringen. In deze hoofdstuk- 
ken trachten we de interne gang van zaken uit de weg te gaan. Daarom zijn 
deze hoofdstukken geschikt zowel voor individuele lezers als voor beginnende 
studenten die willen weten wat een besturingssysteem is zonder op de details in 
te gaan van de interne algoritmen. 

De hoofdstukken 4 tot en met 8 handelen over de klassieke interne algorit- 
men en structuren van besturingssystemen: CVE-werkindeling, geheugenbeheer en 
het beheer van randapparatuur. Deze hoofdstukken geven een gedegen praktisch 
begrip van de gebruikte algoritmen: hun eigenschappen en voor- en nadelen. 
De algoritmen worden in een natuurlijke volgorde gepresenteerd, zodat nieuwe, 
gecompliceerdere systemen kunnen worden opgebouwd op basis van het begrip 
dat men heeft verkregen van eenvoudigere systemen. 

In hoofdstuk 9 wordt het concept geïntroduceerd dat diverse zaken onder 
één noemer samenvat, namelijk dat het computersysteem kan worden opgevat 
als een verzameling van met elkaar samenwerkende sequentiële processen. De 
hoofdstukken 10, 11, 12 en 13 brengen geavanceerde onderwerpen en huidige 
trends, met inbegrip van hogere programmeertalen voor parallel-programmering, 
beveiligingssystemen, de grondbeginselen van systeemontwerp en gedistribueer- 
de systemen. Er wordt nog steeds onderzoek op deze gebieden verricht, zodat 
herzieningen in de nabije toekomst heel goed nodig kunnen zijn. We nemen deze 
onderwerpen echter in dit boek op om twee redenen. Ten eerste is men het er 
algemeen over eens dat deze onderwerpen van belang zijn en studenten ermee 
geconfronteerd moeten worden, ook al is het onderzoek nog in volle gang en 
zoekt men voor de bestaande problemen nog naar definitieve oplossingen. Ten 
tweede maken bestaande systemen van de besproken oplossingen gebruik en zal 
iedereen die in de komende vijf jaar met besturingssystemen werkt op de hoogte 
dienen te zijn van de ontwikkelingen op dit gebied. 

In antwoord op veler verzoek hebben we (bij de tweede druk in het Engels 
— Vert.) een nieuw hoofdstuk toegevoegd om te illustreren hoe de vele uiteen- 


gezette begrippen kunnen worden samengevoegd in een werkelijk systeem. We 
hebben als voorbeeld van een werkelijk systeem het Unix-besturingssysteem, met 
name Berkeley 4.2 BSD, gekozen. Dit besturingssysteem werd gedeeltelijk geko- 
zen omdat het op een gegeven moment klein genoeg was om er een goed begrip 
van te kunnen krijgen, zonder dat het nochtans een ’speelgoed’besturingssysteem 
is. De meeste interne algoritmen ervan werden uitgekozen om hun eenvoud, en 
niet om hun snelheid of omdat ze zo slim in elkaar zitten. Voor informatica- 
afdelingen is Unix direct beschikbaar, zodat veel studenten Unix misschien al 
wel eens hebben gebruikt. 

Aan het eind van elk hoofdstuk zijn bibliografische verwijzingen opge- 
nomen voor verdere studie. Hoofdstuk 15 is in wezen een groep referenties voor 
verdere studie, betrekking hebbend op het gehele boek. In dat hoofdstuk worden 
in het kort enige van de invloedrijkste besturingssystemen beschreven. 


Organisatie 


Besturingssystemen begonnen laat in de jaren ’50 hun intrede te doen en onder- 
gingen twintig jaar lang grote veranderingen in denkbeelden en technieken. Als 
gevolg daarvan trachtten de eerste-generatie leerboeken die gedurende deze pe- 
riode verschenen (zoals Brinch Hansen [1973a], Madnick en Donovan [1974], 
Shaw [1974], Tsichritzis en Bernstein [1974]) een onderwerp uiteen te zetten dat 
zelfs tijdens ‘het schrijven van deze boeken veranderde. 

Nu blijken evenwel de theorie en praktijk van besturingssystemen volgroeid 
en gestabiliseerd te zijn. De basisbegrippen betreffende besturingssystemen zijn 
nu goed gedefinieerd en worden heel wel begrepen. Hoewel er ongetwijfeld nieu- 
we algoritmen zullen komen, is het niet waarschijnlijk dat de fundamentele be- 
nadering van CVE-werkindeling, geheugenbeheer, de koppeling met de gebrui- 
ker, enzovoort, zal veranderen. Er worden weinig besturingssystemen geschreven 
die werkelijk nieuw zijn. De meeste grote computersystemen gebruiken bestu- 
ringssystemen die in de jaren ’60 werden ontworpen. De nieuwste besturingssys- 
temen worden ontwikkeld voor de grote massa microcomputersystemen, maar 
dit zijn in het algemeen CP/M, Unix, of een imitatie hiervan. Het is nu mogelijk 
een boekte schrijven dat klassieke stof over besturingssystemen bevat die alge- 
meen begrepen en aanvaard is. 

Dit boek behoort tot wat we zouden kunnen noemen de tweede-generatie 
leerboeken over besturingssystemen (zoals Calingaert [1982]). Onze tekst ver- 
schilt van andere leerboeken wat betreft het niveau van de inhoud en de opzet. 
De basisbegrippen zijn zorgvuldig geordend en gepresenteerd; de leerstof ver- 
toont een natuurlijke overgang van deze basisprincipes naar de meer ingewikkel- 
de principes. 

Het enige punt waarop men met ons van mening kan verschillen is de volg- 
orde, met name het feit dat het formele procesmodel pas wordt gedefinieerd in 
hoofdstuk 9. Bijna elk ander leerboek plaatst deze stof aan het begin als hoofd- 


xiv 


stuk 2. Het is onze ervaring dat deze rangschikking niet werkt. Het procesmodel 
is een krachtig en handig concept om dingen onder één noemer samen te vatten. 
Echter, bij de eerste introductie van besturingssystemen kent de student de basis- 
principes niet. Om profijt te hebben van het procesmodel moet hij begrijpen hoe 
CVE-werkindeling en geheugenbeheer kunnen worden gezien als afzonderlijke 
virtuele processoren, elk met zijn eigen virtuele geheugen. Dan en dan alleen zal 
de student werkelijk in staat zijn te begrijpen waarom het procesmodel nuttig is. 
Heeft hij eenmaal de juiste achtergrond om het procesmodel van besturingssys- 
temen naar waarde te schatten, dan kan de standaardstof met betrekking tot 
processen, procescoördinatie, -synchronisatie en -communicatie aan de orde ko- 
men. 

Parallelverwerking (concurrency) in de vorm van overlappende in- en uit- 
voer, spool-verwerking, multiprogrammering en tijddeling (time-sharing), wor- 
den al meteen in hoofdstuk 1 geïntroduceerd. Wij denken echter dat het formele 
procesmodel beter kan wachten tot de basisbegrippen (CVE-werkindeling en ge- 
heugenbeheer) goed begrepen zijn. 


De tweede (Engelse) druk 


Vele opmerkingen en suggesties hebben ons bereikt met betrekking tot de eerste 
druk. Deze hebben, gevoegd bij onze eigen bevindingen opgedaan tijdens onze 
colleges aan de Universiteit van Texas en onze cursussen bij IBM, ons ertoe aan- 
gezet deze tweede druk te verzorgen. Onze basisprocedure was daarbij het op- 
nieuw ordenen en herschrijven van de stof in elk hoofdstuk, het up to date maken 
van wat oudere stof, het verbeteren van de opgaven en het toevoegen van een 
nieuw hoofdstuk over Unix. 

Belangrijke wijzigingen werden aangebracht in de volgende hoofdstukken: 


@ Hoofdstuk 1. Een nieuwe ordening houdt de aspecten van het prestatiever- 
mogen en de beveiliging van besturingssystemen duidelijk gescheiden. 


@ Hoofdstuk 3. Voor het verkrijgen van een natuurlijker informatiestroom is een 
aantal paragrafen anders gerangschikt, waarbij eerst bestanden worden be- 
sproken en daarna adresboeken (directories). 


@ Hoofdstuk 8. Een aantal nieuwe voorbeelden illustreert het gedrag van de ver- 
schillende algoritmen. Paragraaf 8.6, over het oplossen van impasses, is her- 
schreven om een betere opzet te verkrijgen. 


@ Hoofdstuk 9. Paragraaf 9.5 is herschreven om de stof up to date te maken. 
Met name is een nieuwe, beknoptere definitie van het kritieke-sectieprobleem 
toegevoegd. Het algoritme van Dekker voor het synchroniseren van twee 
processen is vervangen door het algoritme van Peterson, en er is een nieuw 
synchronisatie-algoritme dat gebruik maakt van speciale apparatuur (hard- 


ware)-instructies (te weten: ’Test-en-Zet’) opgenomen. De paragraaf over het 
RC 4000 systeem is vervangen door een bespreking van het modernere Accent 
systeem. 


@ Hoofdstuk 13. Er is een nieuw gedeelte over het Byzantijnse probleem toege- 
voegd. 


@ Hoofdstuk 14. Een probleem bij studenten (en docenten) die de eerste druk 
gebruikten was, dat zij zich overweldigd voelden door de grote hoeveelheid 
oplossingen voor de vele aspecten van besturingssystemen. Het was moeilijk 
in te zien hoe een compleet systeem al deze stukken aan elkaar zou passen. 
Om aan dit probleem iets te doen hebben we een hoofdstuk toegevoegd over 
een compleet besturingssysteem. Aanvankelijk wisten we niet goed of we een 
‘papieren’ systeem moesten ontwerpen (zoals dat wat gebruikt wordt in Lister 
[1979]) of een werkelijk systeem. We hebben besloten een werkelijk systeem te 
presenteren. Het volgende probleem was het kiezen van een specifiek systeem. 
We hebben Unix gekozen, met name 4.2 BSD. 


@ Hoofdstuk 15. Aangezien een nieuw hoofdstuk 14 werd toegevoegd, is het oude 
hoofdstuk 14 (zonder het gedeelte over Unix) nu hoofdstuk 15 geworden. 


Errata 


We hebben getracht alle fouten uit het boek te halen, maar er zullen, evenals dat 
met besturingssystemen het geval is, ongetwijfeld nog enige verborgen fouten 
inzitten. We zouden het op prijs stellen indien u, lezer, ons op mogelijke fouten 
of omissies in het boek attent wilde maken. Als u verbeteringen wilt voorstellen 
of opgaven bijdragen, dan zouden we dit graag van u vernemen. 
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INLEIDING 


Een besturingssysteem is een programma dat het contact onderhoudt tussen een 
computergebruiker en de computerapparatuur. Een besturingssysteem heeft tot 
doel een werkomgeving te creëren die het de gebruiker mogelijk maakt program- 
ma’s uit te voeren. Het hoofddoel van een besturingssysteem is derhalve het ge- 
bruiksgemak. Een nevendoel is het efficiënt gebruik van de computerapparatuur. 

Om te begrijpen wat besturingssystemen zijn is het nodig dat we begrijpen 
hoe deze tot ontwikkeling zijn gekomen. In dit hoofdstuk gaan we de ontwikke- 
ling van besturingssystemen na, vanaf de eerste systemen die men eigenhandig 
moest bedienen (hands-on systems) tot de tegenwoordige systemen met multipro- 
grammering en tijddeling (time-sharing). Bij het doorlopen van de verschillende 
stadia zullen we zien hoe de componenten van besturingssystemen zich hebben 
ontwikkeld als natuurlijke oplossingen voor problemen die zich voordeden in 
computersystemen uit de begintijd. Het begrijpen van de redenen die aanleiding 
gaven tot de ontwikkeling van besturingssystemen geeft een goed idee van wat 
een besturingssysteem doet en hoe het dit doet. 


1.1 Wat is een besturingssysteem? 


Een besturingssysteem is een belangrijk onderdeel van vrijwel elk computersys- 
teem. Een computersysteem kan ruwweg in vier componenten worden verdeeld 
(zie figuur 1.1): | 


@ De apparatuur (centrale verwerkingseenheid of CVE, geheugen, in- en uitvoer- 
apparatuur). 

@ Het besturingssysteem. 

@ De toepassingsprogramma’s (compileerprogramma’s, database-systemen, 
video-spelletjes, zakelijke programma’s). 

@ De gebruikers (mensen, machines of andere computers). 
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Figuur 1.1 
Abstract overzicht van een computersysteem. 


1.1 Wat is een besturingssysteem? 


De apparatuur levert de fundamentele computersysteemfaciliteiten. De toe- 
passingsprogramma’s bepalen hoe deze systeemfaciliteiten worden gebruikt om 
met behulp van de computer de problemen van de gebruikers op te lossen. Er 
kunnen tal van gebruikers zijn die allerlei problemen hebben op te lossen. Bij- 
gevolg kunnen er een groot aantal verschillende toepassingsprogramma’s zijn. 
Het besturingssysteem bestuurt en coördineert het gebruik van de apparatuur 
door de diverse toepassingsprogramma’s ten dienste van de verschillende gebrui- 
kers. 

Een besturingssysteem heeft wel wat weg van een regering. De basiselemen- 
ten van een computersysteem worden geleverd door de apparatuur (hardware), 
de programmatuur (software) en de gegevens (data). Het besturingssysteem levert 
de middelen voor het juiste gebruik van deze faciliteiten in de werking van het 
computersysteem. Het besturingssysteem vervult, evenals een regering, op zich- 
zelf geen nuttige functie. Het zorgt gewoon voor een werkomgeving waarin andere 
programma’s nuttig werk kunnen doen. 

We kunnen een besturingssysteem zien als een programma belast met het 
toewijzen van systeemfaciliteiten. Een computersysteem beschikt over vele sys- 
teemfaciliteiten (apparatuur en programmatuur) die nodig kunnen zijn om een 
probleem op te lossen: CVE-tijd, geheugenruimte, bestandsopslagruimte, appara- 
tuur voor in- en uitvoer (Input/Output of I/O), enzovoort. Het besturingssys- 
teem treedt op als de beheerder van deze systeemfaciliteiten door deze aan speci- 
fieke programma’s en gebruikers toe te wijzen, naar gelang de taken die ze hebben 
te verrichten. Aangezien er vele, mogelijk strijdige, verzoeken om systeemfacilitei- 
ten kunnen voorkomen, moet het besturingssysteem beslissen aan welke verzoe- 
ken kan worden voldaan om het computersysteem eerlijk en efficiënt te laten 
werken. 

Een enigszins ander gezichtspunt ten aanzien van een besturingssysteem 
krijgt men door te letten op de noodzaak tot besturing van de diverse in- en 
uitvoerapparaten en gebruikersprogramma’s. Een besturingssysteem is een pro- 
gramma dat dit alles bestuurt en beheert: in het Engels een control program. (Ten 
minste drie besturingssystemen hebben dit gezichtspunt in hun naam beli- 
chaamd. Het hoofdbesturingssysteem voor de meeste computers van Burroughs 
is MCP, het Master Control Program; CP/67 is een Control Program voor de 
IBM 360/67; en CP/M, het populaire besturingssysteem voor microcomputers, 
is een Control Program voor Microcomputers.) Een besturingsprogramma be- 
stuurt het uitvoeren van gebruikersprogramma’s, dit ter voorkoming van fouten 
en onjuist gebruik van de computer. Het draagt speciaal zorg voor de werking en 
besturing van in- en uitvoerapparatuur. 

In algemene zin is er evenwel geen definitie te geven die aan alle aspecten 
van een besturingssysteem volledig recht doet. Besturingssystemen zijn er omdat 
ze een redelijke oplossing vormen voor het probleem van het creéren van een 
bruikbaar computersysteem. Het fundamentele doel van een computersysteem is 
het bieden van een oplossing voor de problemen van de gebruikers, in de vorm 
van het uitvoeren van gebruikersprogramma’s. Hierop is de fabricage van compu- 
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terapparatuur gericht. Omdat de kale apparatuur zonder meer niet goed te ge- 
bruiken is, ontwikkelt men toepassingsprogramma’s. Deze programma’s van. uit- 
eenlopende aard vereisen bepaalde gemeenschappelijke bewerkingen, zoals de 
besturing van in- en uitvoerapparatuur. De gemeenschappelijke functies van het 
beheer over en de toewijzing van systeemfaciliteiten worden dan bijeengebracht 
in één stuk programmatuur: het besturingssysteem. 

Het is misschien gemakkelijker een definitie te geven van besturingssys- 
temen aan de hand van wat ze doen dan wat ze zijn. Het hoofddoel van een 
besturingssysteem is het gemak voor de gebruiker. Besturingssystemen bestaan 
omdat ze het gebruik van computers met een besturingssysteem gemakkelijker 
moeten maken dan zonder een besturingssysteem. Dit is met name duidelijk wan- 
neer men kijkt naar besturingssystemen voor kleine computers voor persoonlijk 
gebruik. 

Een nevendoel is de efficiënte werking van het computersysteem. Dit doel 
is speciaal van belang voor grote gemeenschappelijke systemen met meerdere 
gebruikers. Deze systemen zijn gewoonlijk erg kostbaar, en dus is het wenselijk 
ze zo efficiënt mogelijk te maken. Deze twee doelstellingen, gebruiksgemak en 
efficiëntie, zijn soms met elkaar in tegenspraak. In het verleden werd vaak meer 
belang gehecht aan efficiëntie-overwegingen dan aan gebruiksgemak. Dienten- 
gevolge draait het in de theorie van besturingssystemen veelal om een optimaal 
gebruik van computersysteemfaciliteiten. 

Laten we, om te begrijpen wat besturingssystemen zijn en wat ze doen, eens 
zien hoe ze zich in de laatste dertig jaar hebben ontwikkeld. Door die evolutie 
na te gaan kunnen we de gemeenschappelijke faciliteiten van besturingssystemen 
identificeren en inzicht krijgen in het hoe en waarom van deze ontwikkeling. 

Besturingssystemen en de architectuur van computers hebben een grote in- 
vloed op elkaar uitgeoefend. Men heeft besturingssystemen ontwikkeld om het 
gebruik van de apparatuur te vergemakkelijken. Met het ontwerpen en gebruiken 
van besturingssystemen werd het duidelijk dat veranderingen in de bouw van 
de apparatuur het besturingssysteem zouden kunnen vereenvoudigen. In het nu 
volgende, korte historische overzicht moet u er eens op letten hoe met de komst 
van nieuwe voorzieningen in de apparatuur veel problemen op het gebied van 
besturingssystemen op natuurlijke wijze werden opgelost. 


1.2 De eerste systemen 


Aanvankelijk was er alleen computerapparatuur. De eerste computers waren (fy- 
siek) zeer grote machines die vanaf een bedieningspaneel werden bediend. De 
programmeur schreef een programma om dit daarna rechtstreeks vanaf het ope- 
rateur-bedieningspaneel te draaien. Eerst werd het programma met de hand in 
het geheugen geladen, met behulp van de schakelaars op het frontpaneel of vanaf 
ponsband of ponskaarten. Dan werden de juiste knoppen ingedrukt om het be- 
ginadres te laden en de uitvoering van het programma te starten. Tijdens de 
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uitvoering van het programma kon de programmeur/operateur de verwerking 
volgen door het aflezen van de controlelampjes op het bedieningspaneel. Bij het 
ontdekken van fouten kon de programmeur het programma stopzetten, de geheu- 
gen- en registerinhouden nagaan en fouten in het programma rechtstreeks vanaf 
het bedieningspaneel corrigeren. Uitvoergegevens werden afgedrukt, of in pons- 
band of ponskaarten geponst om later te worden afgedrukt. 

Een belangrijk aspect van het werken op deze manier was het interactieve 
eigenhandig bedienen van de computer. De programmeur was tevens de operateur. 
Voor de meeste systemen maakte men gebruik van een intekenlijst of reserverings- 
rooster voor het krijgen van machinetijd. Wilde men de computer gebruiken, dan 
ging men naar de intekenlijst, zocht de volgende geschikte tijd op waarop de 
machine vrij was en tekende daarvoor in. 

Er gingen evenwel met deze aanpak zekere problemen gepaard. Stel dat je 
had ingetekend voor een uur computertijd om een programma te draaien dat je 
aan het maken was. Het zou kunnen gebeuren dat je op een bijzonder lastige fout 
stuitte, waardoor je niet binnen het uur gereed kwam. Als nu iemand het volgende 
tijdblok had gereserveerd, zou je moeten stoppen, daarbij zoveel mogelijk gege- 
vens verzamelen, en later terugkomen om verder te gaan. Daartegenover staat 
dat als alles goed ging, je misschien in 35 minuten klaar zou zijn. Ervan uitgaande 
dat je de machine langer nodig zou hebben, had je ingetekend voor een uur, en 
dus zou de machine dan 25 minuten lang zonder werk zitten. 

Na verloop van tijd werden meer programmatuur en apparatuur ontwik- 
keld. Kaartlezers, regeldrukkers en magneetband werden gemeengoed. Assem- 
bleer-, laad- en montageprogramma’s werden ontworpen om de taak van het 
programmeren te verlichten. Men zette bibliotheken op van gemeenschappelijke 
functies. Deze konden dan in een nieuw programma worden gekopieerd zonder 
dat ze opnieuw behoefden te worden geschreven. 

De routines die de in- en uitvoer van gegevens verzorgden waren speciaal 
van belang. Elk nieuw randapparaat vertoonde zijn eigen kenmerken en vereiste 
daarom zorgvuldig programmeren. Men schreef een speciale subroutine voor 
ieder randapparaat. Zo’n subroutine noemt men een stuurprogramma voor rand- 
apparatuur. Dit weet hoe de buffers, indicatiebits, registers, besturings- en status- 
bits voor een bepaald randapparaat gebruikt moeten worden. Met een eenvou- 
dige taak, zoals het lezen van een letterteken van een ponsbandlezer, kan een 
complexe reeks van apparatuur-afhankelijke bewerkingen gemoeid zijn. In plaats 
van het telkens opnieuw schrijven van de benodigde code, gebruikte men gewoon 
het stuurprogramma uit de bibliotheek. 

Later kwamen er vertaalprogramma’s (compileerprogramma’s; Engels: 
compilers) voor FORTRAN, COBOL en andere talen, waarmee de taak van het 
programmeren veel gemakkelijker, maar het geheel van computerwerkzaamheden 
complexer werd. Om bijvoorbeeld een FORTRAN-programma voor uitvoering 
gereed te maken, moest de programmeur eerst het FORTRAN-vertaalprogram- 
ma in de computer laden. Het vertaalprogramma werd gewoonlijk op magneet- 
band bewaard; dus de juiste band moest worden opgezet op een magneetband- 
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eenheid. Het programma werd dan gelezen door de kaartlezer en weggeschreven 
naar een andere magneetband. Het FORTRAN-vertaalprogramma produceerde 
uitvoer in de assembleertaal, die dan geassembleerd moest worden. Dit vereiste 
het opzetten van weer een magneetband met een ander soort vertaalprogramma 
(assembleerprogramma; Engels: assembler) erop. De uitvoer van het assembleer- 
programma moest in verbinding worden gebracht met de aanvullende biblio- 
theekroutines. Tenslotte was dan de binaire doelvorm van het programma gereed 
om te worden uitgevoerd. Deze kon in het geheugen worden geladen en de fouten 
erin konden, net als daarvoor, vanaf het bedieningspaneel worden opgespoord. 

Merk op dat er met het uitvoeren van een programma een aanzienlijke hoe- 
veelheid opstellingstijd gemoeid kon zijn. Iedere bewerking (job) bestond uit ver- 
schillende stappen (job steps): het laden van de magneetband met het FOR- 
TRAN-compileerprogramma, het draaien van het compileerprogramma, het ver- 
wijderen van de band met het compileerprogramma, het laden van de band met 
het assembleerprogramma, het verwijderen van de band met het assembleerpro- 
gramma, het laden van het doelprogramma en het draaien van het doelprogram- 
ma. Zou er een fout optreden bij één van deze stappen, dan zou men wellicht 
opnieuw moeten beginnen bij het begin. Iedere stap van de bewerking zou kun- 
nen inhouden dat er magneetbanden, ponsbanden en/of ponskaarten moeten 
worden opgezet en weer verwijderd. | 


1.3 Eenvoudige monitor 


De opstellingstijd voor een bewerking was een echt probleem. Al de tijd dat 
magneetbanden moesten worden opgezet, of de programmeur aan het bedie- 
ningspaneel stond, zat de centrale verwerkingseenheid (CVE) zonder werk. Zoals 
u zich herinnert, waren er in die begintijd slechts heel weinig computers en deze 
waren bijzonder kostbaar (miljoenen dollars). Bijvoorbeeld, een IBM systeem 
7094 kostte 2 miljoen dollar en ging niet langer mee dan 5 jaar. Aan afschrijving 
is dat ruim 45 dollar per uur, 24 uur per dag, 365 dagen per jaar. Daar komen 
bij de lopende kosten van energievoorziening, koeling, papier, programmeurs, 
enzovoort. Dit was in een tijd dat het minimumloon in de V.S. 1 dollar was. 

Computertijd was derhalve zeer duur, en de eigenaars van een computer 
wilden dat deze zoveel mogelijk gebruikt werd. Zij hadden een hoge gebruiksfac- 
tor nodig om zoveel mogelijk uit hun investeringen te halen. 

De oplossing was tweevoudig. Ten eerste werden er professionele compu- 
ter-operateurs aangesteld. De programmeur hoefde niet langer de machine te 
bedienen. Zodra een job (bewerking) was beéindigd, kon de operateur de volgen- 
de starten; er was geen leeglooptijd als gevolg van het reserveren van computer- 
tijd die niet nodig bleek te zijn. Omdat een operateur meer ervaring had in het 
opzetten van magneetbanden dan een programmeur, werd de opstellingstijd te- 
ruggebracht. De gebruiker leverde alle kaarten of banden die nodig waren, alsook 
een korte omschrijving hoe de job gedraaid moest worden. De operateurs konden 
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natuurlijk aan het bedieningspaneel geen programmafouten opsporen, aangezien 
zij het programma niet zouden begrijpen. Daarom werd er een afdruk (dump) 
van het geheugen en de registers gemaakt, en de programmeur moest de fouten 
opsporen met behulp van de dump. Dit zorgde ervoor dat de operateurs onmid- 
dellijk met de volgende job verder konden gaan, al bleef de programmeur zitten 
met het probleem dat het opsporen van fouten nu veel moeilijker was. 

De tweede grote tijdsbesparing had te maken met het terugbrengen van de 
opstellingstijd. Jobs met gelijksoortige behoeften werden samengevoegd tot een 
groep (batch), en als groep door de computer verwerkt. Stel bijvoorbeeld dat de 
operateurs een FORTRAN-, een COBOL-, en nog een FORTRAN-job ontvin- 
gen. Als ze die in deze volgorde zouden draaien, zouden ze de opstelling hebben 
moeten maken voor FORTRAN (laad de magneetband met het FORTRAN- 
compileerprogramma, enzovoort), dan de opstelling voor COBOL, en dan op- 
nieuw de opstelling voor FORTRAN. Draaiden ze evenwel de twee FORTRAN- 
programma’s als een groep, dan konden ze volstaan met het geheel slechts een- 
maal op te zetten voor FORTRAN en aldus operateurstijd uitsparen. 

Deze veranderingen, het duidelijk van elkaar scheiden van de operateur en 
de gebruiker en het als groep draaien van gelijksoortige jobs, bracht een grote 
verbetering in de gebruiksfactor. Programmeurs leverden hun programma’s in 
bij de operateurs. De operateurs sorteerden deze tot groepen met gelijksoortige 
vereisten, en draaiden elke groep naar gelang van het beschikbaar komen van de 
computer. De uitvoer van iedere job werd naar de juiste programmeur terugge- 
stuurd. 

Maar er waren nog steeds problemen. Bijvoorbeeld, als een job stopte moes- 
ten de operateurs dat in de gaten hebben door op het bedieningspaneel te letten, 
vaststellen waarom het programma was gestopt (normale of abnormale beëindi- 
ging), zo nodig een dump maken en vervolgens de kaartlezer of ponsbandlezer 
vullen met de volgende job en de computer opnieuw starten. Gedurende deze 
overgang van de ene job naar de andere stond de computer stil. 

Om deze leeglooptijd tegen te gaan werd het automatisch op volgorde verwer- 
ken van jobs ingevoerd, en daarmede werd het eerste rudimentaire besturingssys- 
teem geschapen. Wenselijk was een procedure voor de automatische overdracht 
van de besturing van de ene job naar de volgende. Er werd voor dit doel een 
klein programma, een residente monitor (programma dat toeziet op de verwerking 
en deze regelt), gemaakt (zie figuur 1.2). De residente monitor is permanent aan- 
wezig (resident) in het geheugen. 

Om te beginnen (wanneer de computer werd aangezet) berustte de bestu- 
ring van de computer bij de residente monitor, die dan de besturing overdroeg 
aan een programma. Aan het einde van het programma gaf het de besturing terug 
aan de residente monitor, die dan verder ging met het volgende programma. Op 
deze manier deed de residente monitor automatisch de achtereenvolgende ver- 
werking van programma’s en jobs. 

Maar hoe moest de residente monitor weten welk programma aan de beurt 
was om uitgevoerd te worden? Tevoren had de operateur een korte beschrijving 
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Figuur 1.2 
Geheugenindeling voor een residente monitor 


gekregen van welke programma’s met welke gegevens gedraaid moesten worden. 
Om die informatie rechtstreeks aan de monitor door te geven voerde men bestu- 
_ringskaarten in. Het idee is heel eenvoudig. Aan het programma of de gegevens 
voor een job voegen we speciale kaarten (besturingskaarten) toe, die aanwijzingen 
voor de residente monitor bevatten en aangeven welk programma gedraaid moet 
worden. Bijvoorbeeld, een normaal gebruikersprogramma zou kunnen vereisen 
dat een van de volgende drie programma’s gedraaid moet worden: het FOR- 
TRAN-compileerprogramma (FTN), het assembleerprogramma (ASM), of het 
gebruikersprogramma. We zouden voor elk van deze drie programma’s een aparte 
besturingskaart kunnen gebruiken: 


$FTN — Voer het FORTRAN-compileerprogramma uit. 
$ASM — Voer het assembleerprogramma uit. 
$RUN — Voer het gebruikersprogramma uit. 


Deze kaarten vertellen de residente monitor welke programma’s gedraaid moeten 
worden. 

We kunnen nog twee besturingskaarten gebruiken om de grenzen van elke 
job aan te geven: 
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$JOB — Eerste kaart van een job. 
SEND — Laatste kaart van een job. 


Deze twee kaarten zouden nut kunnen hebben voor het doorberekenen van de 
kosten voor het gebruik door de programmeur van de systeemfaciliteiten. Men 
kan gebruik maken van parameters om de jobnaam te definiëren, het te belasten 
rekeningnummer, enzovoort. Andere besturingskaarten kunnen voor andere 
functies worden gedefinieerd, zoals het aan de operateur vragen een magneet- 
band op te zetten of te verwijderen. 

Een probleem met besturingskaarten is hoe deze onderscheiden moeten 
worden van gegevens- of programmakaarten. De gebruikelijke oplossing is deze 
te identificeren door middel van een speciaal teken of patroon in de kaart. Ver- 
scheidene systemen maakten gebruik van het dollar-teken ($) in de eerste kolom 
om een besturingskaart aan te duiden. Andere systemen gebruikten een andere 
code. De Job-besturingstaal (Job Control Language, JCL) van IBM gebruikte 
schuine streepjes (//) in de eerste twee kolommen. Figuur 1.3 laat een voorbeeld 
zien hoe een pakje kaarten voor een eenvoudig systeem voor groepsgewijze ver- 
werking (batch-systeem) is samengesteld. 

Een residente monitor heeft aldus verschillende van elkaar te onderscheiden 
delen. Een hoofdbestanddeel wordt gevormd door de besturingskaartvertolker. 
Met tussenpozen heeft deze vertolker een laadprogramma nodig om systeempro- 
gramma’s en toepassingsprogramma’s in het geheugen te laden. Zo maakt een 
laadprogramma deel uit van de residente monitor. Zowel de besturingskaartver- 
tolker als het laadprogramma zullen in- en uitvoer moeten verzorgen, en dus 
heeft de residente monitor een groep stuurprogramma’s voor de randapparatuur. 


programmagegevens 


$LOAD 


te compileren programma yn 


Figuur 1.3 
Kaartenpakket voor een eenvoudig batch-systeem 
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Dikwijls worden de systeem- en toepassingsprogramma’s met dezelfde stuurpro- 
gramma’s voor de randapparatuur verbonden voor het verlenen van continuïteit 
in hun verwerking, alsook voor het besparen van geheugenruimte en program- 
meertijd. 

Deze systemen voor groepsgewijze verwerking functioneren redelijk goed. 
De residente monitor zorgt voor de automatische achtereenvolgende verwerking 
van jobs, zoals aangegeven door de besturingskaarten. Wanneer een besturings- 
kaart aangeeft dat een programma gedraaid moet worden, laadt de monitor dit 
in het geheugen en draagt het de besturing daaraan over. Wanneer het program- 
ma klaar is, geeft het de besturing terug aan de monitor, die de volgende bestu- 
ringskaart leest, het juiste programma laadt, enzovoort. Dit wordt herhaald tot 
alle besturingskaarten voor de job vertolkt zijn. Dan gaat de monitor automatisch 
verder met de volgende job. 


1.4 Prestatievermogen 


Computers, met name de grote mainframes (universele computers), zijn van het 
begin af aan zeer dure machines geweest. Daarom wilden de eigenaars van deze 
machines ze zoveel mogelijk aan het werk houden. Dit geldt zelfs voor de goed- 
kopere microcomputers van vandaag. Microcomputers mogen dan wel niet erg 
duur zijn, het is nog steeds wenselijk ze zoveel mogelijk (nuttig) werk te laten 
doen. 

Men is op batch-systemen met automatische achtereenvolgende verwerking 
van jobs overgestapt om het prestatievermogen op te voeren. Het probleem is, 
heel simpel gezegd, dat mensen uiterst langzaam zijn (in vergelijking met de com- 
puter natuurlijk). Als gevolg daarvan is het wenselijk menselijke handelingen te 
vervangen door besturingssysteem-programmatuur. Het automatisch op rij af- 
handelen van jobs elimineert de noodzaak tot tijdrovende menselijke handelingen 
voor het opzetten en de achtereenvolgende verwerking van jobs. 

Echter, zelfs met automatische achtereenvolgende verwerking van jobs staat 
de centrale verwerkingseenheid vaak stil. Dit probleem heeft te maken met de 
snelheid van de mechanische in- en uitvoerapparaten, die intrinsiek langzamer 
zijn dan elektronische apparatuur. Zelfs een langzame CVE werkt in het micro- 
secondengebied, waarbij miljoenen instructies per seconde worden uitgevoerd. 
Een snelle kaartlezer daarentegen kan ongeveer 1000 kaarten per seconde lezen. 
Zo kan het verschil in snelheid tussen de CVE en zijn randapparatuur een factor 
1000 of meer bedragen. 

De (betrekkelijke) traagheid van de randapparatuur kan inhouden dat de 
CVE dikwijls op I/O staat te wachten. Laten we als voorbeeld het geval nemen 
van een assembleer- of compileerprogramma dat zo’n 300 of meer kaarten per 
seconde kan verwerken. Een snelle kaartlezer daarentegen leest wellicht slechts 
1200 kaarten per minuut (of 20 kaarten per seconde). Dit betekent dat het assem- 
bleren van een programma van 1200 kaarten slechts 4 seconden CVE-tijd vergt, 
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maar 60 seconden inleestijd. Dus staat de CVE 56 van de 60 seconden, ofwel 
93,3% van de tijd, niets te doen. De CVE-gebruiksfactor die daaruit volgt is 
slechts 6,7%. Met uitvoer is het net zo. Het probleem is dat de CVE stilstaat 
terwijl er een 1/O-bewerking aan de gang is, omdat de CVE moet wachten tot de 
I/O klaar is; en wanneer de CVE aan de uitvoering bezig is staat de randappara- 
tuur te wachten. 


1.4.1 Niet-gekoppelde (off-line) verwerking 


Mettertijd hadden verbeteringen in de techniek natuurlijk tot gevolg dat de rand- 
apparatuur sneller werd. Maar de snelheid van CVE’s nam nog sneller toe, zodat 
het probleem niet was opgelost; de CVE was nog steeds sneller dan de randappa- 
ratuur. 

Een veel gebruikte oplossing was dat men de erg langzame kaartlezers (in- 
voerapparatuur) en regeldrukkers (uitvoerapparatuur) verving door magneet- 
bandeenheden. Het merendeel van de computersystemen aan het eind van de 
jaren ’50 en het begin van de jaren ’60 bestond uit batch-systemen die inlazen 
van kaartlezers en wegschreven naar regeldrukkers of ponsmachines. Echter, in 
plaats van de CVE rechtstreeks van kaarten te laten lezen kopieerde men de 
kaarten eerst op magneetband. Wanneer de band voldoende vol was werd deze 
van de eenheid afgenomen en naar de computer overgebracht. Was een kaart 
nodig voor invoergegevens voor een programma, dan werd die van de band ge- 
lezen. Evenzo werd uitvoer weggeschreven naar magneetband en werd wat op de 
band stond later afgedrukt. De kaartlezers en regeldrukkers werden niet-gekop- 
peld (off-line) gestuurd, en niet door de hoofdcomputer (zie figuur 1.4). 
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Figuur 1.4 
(a) Gekoppelde en (b) niet-gekoppelde werking van randapparatuur 
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Er werden twee methoden gebruikt voor niet-gekoppelde verwerking. Men 
ontwikkelde specifieke apparatuur (kaartlezers, regeldrukkers) met rechtstreekse 
uitvoer naar, of invoer van, magneetband. Deze apparatuur had extra voorzienin- 
gen die speciaal voor deze taak waren ontworpen. De andere methode bestond 
hierin dat een kleine computer (zoals de IBM 1401) geheel bestemd werd voor 
de taak van het kopiëren naar en van magneetband. De kleine computer was een 
satelliet van de hoofdcomputer. Satellietverwerking was een van de eerste gevallen 
waarin meerdere computersystemen samenwerken om het prestatievermogen op 
te voeren. 

Het belangrijkste voordeel van niet-gekoppelde verwerking was dat de 
hoofdcomputer niet langer in zijn snelheid beperkt werd door de snelheid van de 
kaartlezers en regeldrukkers, maar enkel door de snelheid van de veel snellere 
magneetbandeenheden. Deze techniek van het gebruiken van magneetband voor 
alle I/O kon worden toegepast op alle apparatuur voor eenheidsrecords (kaart- 
lezers, ponsmachines, plotters, ponsband, printers). 

Bovendien hoeft men geen wijzigingen aan te brengen in de toepassingspro- 
gramma’s voor het overgaan van directe naar niet-gekoppelde I/O. Neem bij- 
voorbeeld een programma dat gedraaid wordt op een systeem waaraan een kaart- 
lezer gekoppeld is. Wanneer het een kaart wil lezen, roept het het kaartlezer- 
stuurprogramma in de residente monitor aan. Als we overgaan op niet-gekoppel- 
de I/O voor de kaartlezer, moet alleen het stuurprogramma worden veranderd. 
Heeft het programma een kaart voor invoergegevens nodig, dan roept het dezelf- 
de systeemroutine aan als daarvoor. Echter, nu is de code voor die routine niet 
het stuurprogramma voor de kaartlezer, maar een aanroep van het stuurprogram- 
ma voor magneetband. In beide gevallen ontvangt het toepassingsprogramma 
hetzelfde kaartbeeld. 

Deze faciliteit, dat een programma met verschillende I/O-apparaten ge- 
draaid kan worden, heet apparatuur-onafhankelijkheid. Apparatuur-onafhan- 
kelijkheid wordt mogelijk gemaakt door het besturingssysteem te laten bepalen 
welk apparaat een programma in feite gebruikt wanneer het om I/O verzoekt. 
Programma’s worden dusdanig geschreven dat deze logische randapparaten ge- 
bruiken. Besturingskaarten (of andere commando’s) geven aan hoe het verband 
moet worden gelegd tussen logische apparaten en de fysieke apparatuur. 

De werkelijke winst van niet-gekoppelde verwerking komt van de mogelijk- 
heid meerdere kaart-naar-band-systemen en band-naar-printer-systemen te ge- 
bruiken voor één CVE. Als de CVE tweemaal zo snel invoergegevens kan verwer- 
ken als de kaartlezer kaarten kan inlezen, kunnen twee kaartlezers die gelijktijdig 
werken genoeg magneetband produceren om de CVE aan het werk te houden. 
Daar staat tegenover dat er nu een grotere vertraging optreedt bij het opstarten 
van een bepaalde job. Deze moet eerst worden gelezen en op band gezet. Dan is 
er een wachttijd tot er genoeg jobs gelezen en op de band gezet zijn tot deze ‘vol’ 
is. De band moet dan worden teruggespoeld, van de eenheid afgenomen en door 
iemand naar de CVE gebracht en op een vrije magneetbandeenheid opgezet wor- 
den. Dit is natuurlijk niet ongunstig voor systemen voor groepsgewijze verwer- 
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king. Een groot aantal gelijksoortige jobs kan als groep (batch) op een band 
worden gezet voordat deze naar de computer wordt gebracht. 


1.4.2 Buffering 


Een andere oplossing voor de traagheid van de randapparatuur is buffering. Met 
buffering streeft men ernaar zowel de CVE als de randapparatuur te allen tijde 
aan het werk te houden. Het idee is heel eenvoudig. Nadat gegevens zijn ingelezen 
en de CVE op het punt staat deze te gaan verwerken, wordt de invoereenheid 
opdracht gegeven meteen met de volgende invoerbewerking te beginnen. De CVE 
en de invoereenheid zijn dan beide aan het werk. Met een beetje geluk zal, tegen 
de tijd dat de CVE klaar is voor het volgende invoergegeven, de invoereenheid 
dit juist gelezen hebben. De CVE kan dan beginnen met het verwerken van het 
zojuist gelezen gegeven, terwijl de invoereenheid het volgende gegeven begint te 
lezen. 

Buffering voor uitvoer gaat op dezelfde manier. In dit geval produceert de 
CVE gegevens die in een buffer gezet worden tot de uitvoereenheid deze kan 
aannemen. 

Een record is een natuurlijke gegevenseenheid. Dit kan een fysiek record 
zijn (zoals een regelbeeld voor een printer, of een teken van een toetsenbord, of 
een blok van een magneetband of schijf), of het kan een logisch record zijn (zoals 
een invoerregel, een Nederlands of Engels woord, of een reeks gegevens). Logi- 
sche records worden bepaald door het toepassingsvraagstuk; fysieke records wor- 
den bepaald door de aard van het randapparaat. Programmatuur voor het blok- 
ken en ontblokken zorgt voor de conversie van logische records van de toepassing 
naar fysieke records van het randapparaat, en andersom. Records zijn de ge- 
gevenseenheden die worden gebruikt voor buffering. 

In de praktijk houdt buffering zelden zowel de CVE als de randapparatuur 
voortdurend aan het werk. Als de CVE aan het ene record werkt terwijl een 
invoereenheid bezig is met een ander, zal óf de CVE óf de invoereenheid het eerst 
klaar zijn. Als de CVE het eerst klaar is moet deze wachten; hij kan niet verder 
gaan totdat het volgende record is ingelezen en in het geheugen klaar staat om 
te worden verwerkt. Merk evenwel op dat de CVE misschien niet lang zonder 
werk zal hoeven te blijven, in het ergste geval niet langer dan zonder buffering. 
Als de invoereenheid het eerst klaar is, moet deze wachten of hij kan verder gaan 
met het lezen van het volgende record. De buffers die records bevatten die nog 
niet zijn verwerkt (of wel verwerkt maar nog niet als uitvoer weggeschreven), 
worden dikwijls voldoende groot gemaakt om verscheidene records te kunnen 
bevatten (bijvoorbeeld een buffer van 255 tekens of 10 kaarten). Aldus kan een 
invoereenheid diverse records op de CVE vóór zijn. Als de invoereenheid echter 
voortdurend sneller is dan de CVE, zal de buffer uiteindelijk vol raken en moet 
de invoereenheid wachten. 

Buffering is een lastige zaak en kan moeilijk te coderen zijn. Eén probleem 
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is zo snel mogelijk te ontdekken dat een randapparaat klaar is met een bewerking. 
De volgende 1/O-bewerking kan alleen gestart worden wanneer de vorige geëin- 
digd is. Onderbrekingen (interrupts) lossen dit probleem op. Zodra een randappa- 
raat met een bewerking klaar is, onderbreekt het de CVE. Wanneer de CVE 
onderbroken wordt, stopt hij met wat hij aan het doen is en draagt onmiddellijk 
de besturing over aan een vaste plaats in het geheugen. De instructies op deze 
plaats vormen gewoonlijk een functieroutine vcor het behandelen van de onder- 
breking. Deze controleert of de buffer niet vol is (voor een invoereenheid), of 
niet leeg (voor een uitvoereenheid), en initieert dan het volgende verzoek om 
I/O. De CVE kan dan de onderbroken verwerking hervatten. Op deze wijze kun- 
nen de randapparatuur en de CVE op volle snelheid werken. 

Onderbrekingen vormen een belangrijk onderdeel van een computerar- 
chitectuur. Elk computerontwerp heeft zijn eigen onderbrekingsmechanisme, al 
hebben verschillende ontwerpen tal van functies gemeen. De onderbreking moet 
de besturing overdragen aan de onderbrekingsfunctieroutine. In het algemeen 
wordt dit gedaan door een groep posities in het lage gedeelte van het geheugen 
(de eerste 100 posities of zo) te reserveren voor het opslaan van de adressen van 
de onderbrekingsfunctieroutines van de diverse randapparaten. Deze reeks, of 
vector, van adressen wordt dan gebruikt om met behulp van het nummer van het 
apparaat als index het adres te vinden van de onderbrekingsfunctieroutine voor 
het apparaat dat de onderbreking veroorzaakte. 

De onderbrekingsarchitectuur moet ook het adres van de onderbroken in- 
structie veilig opbergen. In vele oude ontwerpen werd het adres van de onder- 
broken instructie opgeslagen op een vaste plaats in het geheugen of een plaats die 
wordt gevonden door het apparaatnummer als index te gebruiken. In recentere 
architecturen wordt het terugkeeradres veilig opgeborgen op de systeemstapel. 
Het kan nodig zijn dat de programmeur van de onderbrekingsfunctieroutine an- 
dere registers, zoals optelregisters of indexregisters, zelf opbergt en terugstelt. Na 
afhandeling van de onderbreking wordt met een sprong terug naar het adres van 
de onderbroken instructie de onderbroken verwerking hervat alsof de onder- 
breking niet had plaatsgevonden. Uitgekiende onderbrekingsarchitecturen hou- 
den ook rekening met een onderbreking die optreedt terwijl een andere onder- 
breking wordt afgehandeld, dikwijls door middel van een prioriteitenschema. 

Neem bijvoorbeeld een eenvoudig stuurprogramma voor uitvoer naar een 
terminal (eindstation of werkstation). Als er een regel op de terminal moet wor- 
den afgebeeld wordt het eerste teken naar de terminal gestuurd. Wanneer dat 
teken verschijnt zal de terminal de CVE onderbreken. Wanneer het onder- 
brekingsverzoek van de terminal aankomt zal de CVE op het punt staan een of 
andere instructie uit te voeren. (Als de CVE middenin de uitvoering van een 
instructie zit wordt de onderbreking opgehouden tot de uitvoering van de instruc- 
tie voltooid is.) Het adres van deze onderbroken instructie wordt veilig gesteld 
en de besturing overgedragen aan de onderbrekingsfunctieroutine voor de uit- 
voerterminal. 

De onderbrekingsfunctieroutine stelt de inhoud van alle registers die hij zal 
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moeten gebruiken veilig. De routine controleert op mogelijke foutcondities die 
ontstaan zouden kunnen zijn als gevolg van de laatste uitvoerbewerking. Dan 
wordt de buffer gecontroleerd of deze tekens bevat die nog moeten worden afge- 
beeld. Zitten er nog tekens in de buffer, dan wordt er één uit de buffer gehaald. 
Wijzer- en tellervariabelen worden op de juiste wijze bijgewerkt. Het teken wordt 
op de terminal afgebeeld en besturingsbits worden gezet om het de terminal mo- 
gelijk te maken na correcte afbeelding van het teken de CVE opnieuw te onder- 
breken. Dan herstelt de onderbrekingsfunctieroutine de inhoud van die registers 
waarvan de inhoud was veilig gesteld, en wordt de besturing teruggegeven aan 
de onderbroken instructie. 

Als tekens worden uitgevoerd naar een 1200-bauds terminal, kan deze ter- 
minal één teken per ongeveer 8 milliseconden, ofwel 8000 microseconden, aanne- 
men en afbeelden. Een goedgeschreven onderbrekingsfunctieroutine voor het uit- 
voeren van tekens van een buffer naar het beeldstation kan 20 microseconden 
per teken nodig hebben, waardoor 7980 van elke 8000 microseconden overblijven 
voor verwerking door de CVE (en het afhandelen van andere onderbrekingen). 
Een zeer snel randapparaat echter, zoals een magneetband, schijf of communi- 
catienetwerk, kan wel informatie verzenden met een snelheid die die van het 
geheugen nabij komt. De CVE zou dan 20 microseconden nodig hebben om op 
onderbrekingen te reageren, terwijl er (bijvoorbeeld) iedere 4 microseconden een 
onderbreking binnenkomt. 

Om dit probleem op te lossen wordt voor zeer snelle randapparatuur ge- 
bruik gemaakt van Directe GeheugenToegang (DGT). Na het opzetten van buf- 
fers, wijzers en tellers voor het randapparaat, brengt dit een geheel blok met 
gegevens rechtstreeks naar of van het geheugen over, zonder tussenkomst van de 
CVE. Per blok wordt slechts één onderbreking gegenereerd, in plaats van telkens 
een onderbreking per byte (of woord) voor de langzame randapparatuur. 

De fundamentele werking van de CVE blijft gelijk. Wanneer een DGT- 
apparaat de CVE onderbreekt, controleert de onderbrekingsfunctieroutine op 
fouten in de vorige gegevensoverbrenging. Dan haalt hij een buffer (een lege 
buffer voor invoer of een volle buffer voor uitvoer) uit een buffer-wachtrij voor 
de volgende overbrenging van gegevens. (Een buffer is gewoonlijk 128 tot 4096 
bytes, afhankelijk van het randapparaat.) Het adres en de grootte van de buffer 
worden in bij het apparaat behorende registers gezet, waarna de I/O-bewerking 
wordt gestart. De volgende onderbreking door het randapparaat geeft aan dat 
het gehele blok is overgebracht (of dat er een fout is opgetreden). 

Let erop dat buffering direct te maken heeft met het verwerken van onder- 
brekingen. Dit feit, alsook de moeilijkheid bufferroutines correct te programme- 
ren (wat gebeurt er als we middenin het verwijderen van een record uit de buffer 
zitten en bezig zijn met het bijwerken van de wijzers van de buffer en er een 
onderbreking optreedt?), betekent dat buffering in het algemeen een functie is 
van het besturingssysteem. Tot de residente monitor of de stuurprogramma’s 
voor de randapparatuur behoren systeembuffers voor de 1/O voor elk randappa- 
raat. Subroutine-aanroepen van het stuurprogramma van een randapparaat door 
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toepassingsprogramma’s (verzoeken om I/O) zorgen gewoonlijk alleen voor over- 
brenging naar of van een systeembuffer. De eigenlijke 1/O-bewerking heeft óf al 
plaatsgehad, óf vindt later plaats zodra het randapparaat beschikbaar is. 

Wat is het effect van buffering op het prestatievermogen? Buffering helpt 
voornamelijk om meer regelmaat aan te brengen in de tijd die nodig is voor het 
verwerken van een record. Als de gemiddelde snelheid (in aantal records per 
seconde) van CVE en randapparatuur dezelfde is, dan kan door buffering de 
CVE iets vóór- of iets achterlopen op de randapparatuur, waarbij beide alles nog 
op volle snelheid verwerken. 

Is echter de CVE gemiddeld veel sneller dan een invoereenheid, dan is buf- 
fering van weinig nut. Als de CVE altijd sneller is, zal deze altijd een lege buffer 
aantreffen en moeten wachten op de invoereenheid. Wat uitvoer betreft, kan de 
CVE op volle snelheid verder gaan tot uiteindelijk alle systeembuffers vol zijn. 
Dan moet de CVE wachten op de uitvoereenheid. Deze situatie doet zich voor 
bij 1/O-gebonden jobs, waarbij de hoeveelheid I/O, vergeleken met de verwerking 
door de CVE, erg groot is. Aangezien de CVE sneller is dan de randapparatuur, 
is de verwerkingssnelheid begrensd door de snelheid van de randapparatuur, niet 
door die van de CVE. 

Anderzijds is voor een CVE-gebonden job de hoeveelheid verwerking door 
de CVE zó groot dat de invoerbuffers altijd vol zijn en de uitvoerbuffers altijd 
leeg; de CVE kan de randapparatuur niet bijhouden. 

Buffering kan dus wel wat helpen, maar dit is zelden voldoende. Vooral in 
de eerste computersystemen waren de meeste jobs 1/O-gebonden. Buffering hielp 
wel iets, maar de randapparatuur (zoals kaartlezers, regeldrukkers en ponsband- 
lezers/-ponsers) waren gewoon te langzaam om de CVE bij te houden. 


1.4.3 Spool-verwerking 


Hoewel niet-gekoppelde voorbereiding van jobs nog een tijd lang voortgang 
vond, werd dit in de meeste systemen snel vervangen. Systemen met schijven- 
geheugens kwamen in ruime mate beschikbaar en brachten aanzienlijke verbete- 
ring in niet-gekoppelde verwerking. Het probleem met magneetbanden was dat 
de kaartlezer niet aan het ene eind van de band kon schrijven terwijl de CVE 
het andere eind inlas. De gehele band moest worden beschreven voordat deze 
teruggespoeld en gelezen werd. Systemen met schijven hielpen dit probleem uit 
de wereld. Door de lees/schrijfkop van het ene gebied van de schijf naar een 
ander te bewegen, kan de schijf snel overschakelen van het gebied dat door de 
kaartlezer in gebruik is om nieuwe kaarten op te slaan, naar de positie die de 
CVE nodig heeft voor het inlezen van de ‘volgende’ kaart. 

In een schijvensysteem worden kaarten rechtstreeks van de kaartlezer ge- 
lezen en op schijf gezet. De plaats van de kaartbeelden wordt vastgelegd in een 
tabel die wordt bijgehouden door het besturingssysteem. Elke job wordt bij het 
inlezen in de tabel genoteerd. Wanneer een job wordt uitgevoerd, wordt aan zijn 
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verzoeken om invoergegevens van de kaartlezer voldaan door van de schijf te 
lezen. Evenzo wordt, wanneer de job de printer om uitvoer van een regel verzoekt, 
die regel gekopieerd in een systeembuffer en naar schijf geschreven. Pas wanneer 
de job klaar is, wordt de uitvoer afgedrukt. 

Deze vorm van verwerken wordt spool-verwerking genoemd (zie figuur 1.5). 
De term SPOOL is een acroniem voor Simultaneous Peripheral Operations On- 
Line (gelijktijdige bewerkingen van aan de computer gekoppelde randappara- 
tuur). Spool-verwerking gebruikt in wezen de schijf als een zeer grote buffer, om 
bij invoerapparatuur zo ver mogelijk vooruit te lezen, en om uitvoerbestanden 
op te slaan tot de uitvoerapparatuur in staat is deze aan te nemen. 

Buffering overlapt de I/O van een job met zijn eigen verwerking. Het voor- 
deel van spool-verwerking ten opzichte van buffering is dat spool-verwerking de 
I/O van een job overlapt met de verwerking van andere jobs. Zelfs in een eenvou- 
dig systeem kan het spool-programma bezig zijn de invoer van één job te lezen 
en intussen de uitvoer van een andere job afdrukken. Gedurende deze tijd kunnen 
een of meer jobs worden uitgevoerd, die hun ‘kaarten’ van schijf lezen en hun 
uitvoer op schijf ’afdrukken’. Buffering kan alleen de I/O van een job overlappen 
met zijn eigen verwerking en I/O; spool-verwerking kan de I/O en verwerking 
van vele jobs overlappen. 

Spool-verwerking is nu een standaardvoorziening van de meeste systemen, 
maar het was geen integraal onderdeel van het IBM OS/360 systeem voor de 
computers van de 360-serie toen OS/360 in het begin van de jaren ’60 werd geïn- 
troduceerd. In plaats daarvan werd spool-verwerking als een speciale voorziening 
toegevoegd door het rekencentrum van de NASA te Houston. Vandaar dat dit 
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Figuur 1.5 
Spool-verwerking 
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bekend staat als HASP, het Houston Automatische Spool-verwerking Program- 
ma. 

Een extreme vorm van spool-verwerking kan men doen met magneetband. 
Het is mogelijk alles wat op een band staat in te lezen en op schijf te zetten 
alvorens dit te gebruiken. Alle bewerkingen vinden dan plaats op de kopie op 
schijf, met grotere snelheid en zonder slijtage van de band. Deze werkwijze staat 
bekend als het getrapt overbrengen van een magneetband. 

Spool-verwerking heeft een direct gunstig effect op het prestatievermogen. 
Tegen de prijs van wat schijfruimte en een paar tabellen kan de CVE de verwer- 
king van de ene job overlappen met de I/O van andere jobs. Aldus kan spool- 
verwerking zowel de CVE als de randapparatuur in veel hoger tempo aan het 
werk houden, vooral als er een combinatie van CVE-gebonden en I/O-gebonden 
jobs gedraaid moet worden. 

Bovendien levert spool-verwerking een heel belangrijke gegevensstructuur 
op: een jobpot. Spool-verwerking heeft in het algemeen tot gevolg dat verscheide- 
ne jobs zijn ingelezen en staan te wachten op schijf, gereed om gedraaid te wor- 
den. Een jobpot op schijf stelt het besturingssysteem in staat te bepalen welke 
job nu moet draaien, om zo de CVE-gebruiksfactor op te voeren. Komen jobs 
rechtstreeks van kaarten binnen, of zelfs van magneetband, dan is het niet moge- 
lijk jobs over te slaan en in een andere volgorde te draaien. Jobs moeten sequen- 
tieel gedraaid worden, volgens het principe ’wie-het-eerst-komt-het-eerst-maalt’. 
Staan er echter diverse jobs op een apparaat met directe toegang (direct access), 
zoals schijf, dan wordt job-werkindeling (job scheduling) mogelijk. In hoofdstuk 
4 zullen we job- en CVE-werkindeling uitvoeriger bespreken, maar een paar be- 
langrijke aspecten worden hier behandeld. 
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Het belangrijkste aspect van job-werkindeling is de mogelijkheid tot multipro- 
grammering. Niet-gekoppelde verwerking, buffering en spool-verwerking voor 
het overlappen van I/O hebben alle hun beperkingen. Eén gebruiker kan in het 
algemeen niet én de CVE én de randapparatuur altijd maar aan het werk houden. 
Multiprogrammering is een poging de CVE-gebruiksfactor op te voeren door 
altijd iets voor de CVE te hebben dat verwerkt moet worden. 

Het idee is als volgt. Het besturingssysteem selecteert één job uit de pot en 
begint deze uit te voeren. Tenslotte zal de job wel eens ergens op moeten wachten, 
zoals het opzetten van een magneetband, het intikken van een commando op een 
toetsenbord, of het gereedkomen van een I/O-bewerking. In een systeem zonder 
multiprogrammering (uniprogrammering) zou de CVE dan stilstaan. In een mul- 
tiprogrammeringssysteem schakelt het besturingssysteem gewoon over op een an- 
dere job en voert deze uit. Moet die job wachten, dan wordt de CVE op weer 
een andere job overgeschakeld, enzovoort. Uiteindelijk is de eerste job klaar met 
wachten en krijgt hij de CVE terug. Zolang er voortdurend een job is die moet 
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worden uitgevoerd, zal de CVE nooit zonder werk zitten. 

Dit idee is heel gewoon in andere situaties in het dagelijks leven. Een ad- 
vocaat heeft niet maar één cliënt tegelijk. Het zal eerder zo zijn dat verschillende 
cliënten tegelijkertijd van zijn diensten gebruik maken. Terwijl de ene zaak wacht 
om voor te komen of op het uittypen van de stukken, kan de advocaat aan een 
ander geval werken. Met genoeg cliënten hoeft een advocaat nooit zonder werk 
te zitten. (Advocaten zonder werk hebben de neiging in de politiek te gaan, dus 
is er een zeker sociaal belang mee gediend ze aan het werk te houden.) 

Besturingssystemen met multiprogrammering zitten wel knap in elkaar. Om 
verschillende jobs gereed te hebben voor uitvoering, moeten ze alle tegelijk in het 
geheugen gehouden worden (zie figuur 1.6). Voor het tegelijkertijd in het geheu- 
gen hebben van diverse jobs is een of andere vorm van geheugenbeheer nodig, 
hetgeen behandeld wordt in de hoofdstukken 5 en 6. Bovendien moet, als diverse 
jobs op hetzelfde moment voor uitvoering gereed zijn, een bepaalde beslissing 
genomen worden om één ervan te selecteren. Dit is CVE -werkindeling, wat be- 
sproken wordt in hoofdstuk 4. Ook moeten systemen met multiprogrammering 
zorgen voor een werkindeling voor de randapparatuur (hoofdstuk 7), het behan- 
delen van impasses (hoofdstuk 8), besturing van parallelle processen (hoofdstuk 
9) en beveiliging (hoofdstuk 11). Zo is multiprogrammering het centrale thema 
in de moderne besturingssystemen en ook het centrale thema in dit boek. 


Figuur 1.6 
Geheugenindeling voor een multiprogrammeringssysteem 
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1.6 Tijddeling (time-sharing) 


Toen systemen voor groepsgewijze verwerking voor het eerst ontwikkeld werden, 
werden zij bepaald door het tot groepjes (batches) samenvoegen van gelijksoor- 
tige jobs. Systemen die gebaseerd zijn op kaart en magneetband hadden alleen 
de mogelijkheid van sequentiële toegang tot programma’s en gegevens, en dus 
kon er slechts één toepassingsprogramma tegelijk gebruikt worden. 

Toen gekoppelde (online) opslag op schijf mogelijk werd, kon aan alle toe- 
passingssystemen de mogelijkheid van directe toegang worden verschaft. Nu wor- 
den systemen voor groepsgewijze verwerking niet langer bepaald door het tot 
groepjes samenvoegen van jobs maar door andere kenmerken. 

Een besturingssysteem voor groepsgewijze verwerking leest gewoonlijk een 
stroom aparte jobs in, bijvoorbeeld van een kaartlezer, elke job met zijn eigen 
besturingskaarten die van te voren vastleggen wat de job doet. Wanneer de job 
klaar is, worden de uitvoergegevens gewoonlijk afgedrukt (bijvoorbeeld op een 
regeldrukker). Het bepalende kenmerk van een systeem voor groepsgewijze ver- 
werking is het ontbreken van interactie tussen de gebruiker en de job tijdens de 
uitvoering ervan. De job wordt voorbereid en ingediend. Enige tijd later (mi- 
nuten, uren of dagen misschien) verschijnen de uitvoergegevens. De tijd tussen 
het indienen en het gereedkomen van de job, de turnaround-tijd genoemd, is af- 
hankelijk van de hoeveelheid verwerking die nodig is, of van vertragingen voordat 
het besturingssysteem aan de verwerking van de job begint. 

Er zijn echter, vanuit het gezichtspunt van de programmeur of gebruiker 
gezien, enige moeilijkheden met systemen voor groepsgewijze verwerking. Aange- 
zien gebruikers geen mogelijkheid hebben tot interactie met hun jobs terwijl deze 
worden uitgevoerd, moeten ze besturingskaarten aanmaken om in alle mogelijke 
situaties te voorzien. In een job die uit meer dan één stap bestaat kunnen opeen- 
volgende stappen afhankelijk zijn van de resultaten van voorgaande stappen. Het 
draaien van een programma kan bijvoorbeeld ervan afhangen of het compileren 
succesvol verliep. Het kan moeilijk zijn om in alle gevallen volledig aan te geven 
wat er moet gebeuren. 

Een andere moeilijkheid in een systeem voor groepsgewijze verwerking is 
dat opsporing van fouten in programma’s statisch moet plaatsvinden, met behulp 
van dumps die momentopnamen voorstellen. Een programmeur kan een pro- 
gramma niet tijdens de uitvoering wijzigen om de gedragingen ervan te bestu- 
deren. Een lange turnaround-tijd bemoeilijkt het experimenteren met een pro- 
gramma. (Daar staat tegenover dat deze situatie een zekere discipline kan bevor- 
deren in het schrijven en testen van programma’s.) 

Een interactief of hands-on computersysteem geeft gekoppelde (on-line) 
communicatie tussen de gebruiker en het systeem. De gebruiker geeft rechtstreeks 
opdrachten aan het besturingssysteem of aan een programma, en krijgt onmid- 
dellijke reactie. Gewoonlijk wordt een toetsenbord gebruikt voor invoer, en een 
printer of beeldscherm, zoals een kathodestraalbuis (Engels: Cathode Ray Tube, 
of CRT), voor uitvoer. Wanneer het besturingssysteem de uitvoering van een 
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commando heeft voltooid, vraagt het de volgende ’besturingskaart’, niet van een 
kaartlezer maar van het toetsenbord van de gebruiker. De gebruiker geeft een 
commando, wacht op de reactie en baseert zijn beslissing over het volgende com- 
mando op het resultaat van de voorafgaande. De gebruiker kan gemakkelijk ex- 
perimenteren en onmiddellijke resultaten zien. De meeste systemen hebben een 
interactief tekstopmaakprogramma voor het invoeren van programma’s en een 
interactief programma voor het opsporen van fouten om te helpen bij het foutvrij 
maken van programma’s. 

= Systemen voor groepsgewijze verwerking zijn heel geschikt voor het uitvoe- 
ren van grote jobs die weinig interactie nodig hebben. De gebruiker kan deze 
inleveren en later terugkomen voor de resultaten; het is niet nodig dat hij blijft 
wachten terwijl de job wordt verwerkt. Interactieve jobs zijn vaak opgebouwd uit 
vele korte acties, waarbij de resultaten van het volgende commando mogelijk niet 
zijn te voorspellen. De gebruiker tikt het commando in en wacht op de resultaten 
(de ’respons’). Daarom moet de responstijd heel kort zijn, hoogstens in de orde 
van grootte van enkele seconden. Een interactief systeem wordt gekenmerkt door 
de behoefte aan een korte responstijd. 

De eerste computers waren interactieve systemen. Dat wil zeggen, het ge- 
hele systeem stond tot de onmiddellijke beschikking van de programmeur/opera- 
teur. Dit gaf de programmeur een grote flexibiliteit en vrijheid in het testen en 
ontwikkelen van programma’s. Maar, zoals we gezien hebben, deze opzet resul- 
teerde in een aanzienlijke leeglooptijd, waarin de CVE moest wachten op het 
nemen van een of andere actie door de programmeur/operateur. Omdat deze 
eerste computers zo duur waren, was leeglooptijd van de CVE ongewenst. Men 
ontwikkelde systemen voor groepsgewijze verwerking in een poging dit probleem 
te vermijden. Zulke systemen brachten de eigenaars van het computersysteem 
een verbetering in de gebruiksfactor. 

Systemen met tijddeling (Engels: time-sharing) zijn het resultaat van het 
pogen tegen een redelijke prijs interactief gebruik van een computersysteem mo- 
gelijk te maken. 

Een besturingssysteem met tijddeling gebruikt CVE-werkindeling en multi- 
programmering om iedere gebruiker een klein deel van een computer met tijd- 
deling te geven. Iedere gebruiker heeft een afzonderlijk programma in het geheu- 
gen. Wanneer een programma wordt uitgevoerd, draait het normaal gesproken 
slechts een korte tijd voordat het ofwel klaar is of I/O moet doen. I/O kan inter- 
actief zijn; dat wil zeggen: de uitvoer gaat naar het beeldscherm en invoer komt 
van het toetsenbord van een gebruiker. Omdat interactieve I/O gewoonlijk door 
de snelheid van de mens wordt bepaald, kan het lang duren voordat deze voltooid 
is. Invoer bijvoorbeeld wordt begrensd door de typesnelheid; 5 tekens per secon- 
de is aardig snel voor mensen maar erg langzaam voor computers. In plaats van 
de CVE stil te laten staan wanneer dit zich voordoet, zal het besturingssysteem 
snel de CVE overschakelen op het programma van een andere gebruiker. 

Een besturingssysteem met tijddeling stelt de vele gebruikers in staat om 
de computer ‘samen te delen’ (Engels: to share). Omdat iedere actie of commando 
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Verschillende soorten besturingssystemen 


in een systeem met tijddeling gewoonlijk kort duurt, is er voor elke gebruiker 
slechts een klein beetje CVE-tijd nodig. Bij het snel overschakelen van de ene 
gebruiker op de volgende krijgen de gebruikers de indruk dat elk zijn/haar eigen 
computer heeft, terwijl in feite de vele gebruikers één computer samen delen. 
Het idee van tijddeling werd al in 1960 gedemonstreerd, maar omdat het 
moeilijker en kostbaarder is systemen met tijddeling te bouwen, duurde het nog 
tot het begin van de jaren ’70 eer ze op grote schaal gebruikt werden. Met het 
groeien van de populariteit van tijddeling-systemen zijn er pogingen gedaan sys- 
temen voor groepsgewijze verwerking en systemen met tijddeling tot één systeem 
samen te voegen. Vele computersystemen die van oorsprong hoofdzakelijk syste- 
men voor groepsgewijze verwerking waren werden gemodificeerd om zo een sub- 
systeem met tijddeling te creëren. Zo werd bijvoorbeeld IBM OS/360, een sys- 
teem voor groepsgewijze verwerking, gemodificeerd om TSO, de Time-Sharing 
Optie, te ondersteunen. Tegelijkertijd voegde men vaak aan systemen met tijd- 
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deling een subsysteem voor groepsgewijze verwerking toe. Tegenwoordig leveren 
de meeste systemen zowel groepsgewijze verwerking als tijddeling, al is hun basis- 
ontwerp en -gebruik gewoonlijk het een of het ander. 


1.7 Onvertraagde (real-time) systemen 


Nog weer een ander soort besturingssysteem is het onvertraagde ofwel real-time 
systeem. Een onvertraagd systeem wordt vaak gebruikt als een stuurapparaat in 
een op zichzelf staande toepassing. Gevoelige elementen, sensors, brengen gege- 
vens in de computer. De computer moet de gegevens analyseren en eventueel 
stuurgrootheden bijstellen om de invoergegevens van de sensors te wijzigen. Sys- 
temen die wetenschappelijke experimenten besturen, medische computersys- 
temen, industriële regelsystemen, en sommige afbeeldingssystemen, zijn onver- 
traagde systemen. Een onvertraagd besturingssysteem heeft welbepaalde vaste- 
tijdsbeperkingen. De verwerking moet klaar zijn binnen de vastgestelde grenzen, 
of het systeem werkt niet. Vergelijk deze eis met een systeem met tijddeling, 
waarin het wenselijk is (maar niet verplicht) een snelle respons te geven, of met 
een systeem voor groepsgewijze verwerking, waarin wellicht helemaal geen tijds- 
beperkingen nodig zijn. 


18 Beveiliging 


De eerste computersystemen waren systemen voor één gebruiker, die door een 
programmeur werden bediend. Toen programmeurs de computer vanaf het be- 
dieningspaneel bedienden, hadden zij de besturing van het systeem volledig zelf 
in handen. Naarmate er evenwel besturingssystemen tot ontwikkeling kwamen, 
kwam deze besturing te liggen bij het besturingssysteem. Te beginnen bij de re- 
sidente monitor ging het besturingssysteem veel van de functies waarvoor de pro- 
grammeur voordien verantwoordelijk was geweest, in het bijzonder de I/O, over- 
nemen. 

Bovendien begon het besturingssysteem, om de gebruiksfactor van het sys- 
teem op te voeren, verschillende programma’s gemeenschappelijk gebruik van de 
systeemfaciliteiten te verlenen. Met spool-verwerking kon één programma wor- 
den uitgevoerd, terwijl I/O plaatsvond voor andere jobs; de schijf bevatte gege- 
vens voor verschillende jobs tegelijk. Multiprogrammering bracht diverse jobs 
tegelijkertijd in het geheugen. 

Dit gemeenschappelijk gebruik van systeemfaciliteiten leverde zowel een 
betere gebruiksfactor als meer problemen op. Toen het systeem zonder gemeen- 
schappelijk gebruik van systeemfaciliteiten werd gedraaid, kon een fout in een 
programma alleen problemen geven voor dat ene programma dat draaide. Met 
gemeenschappelijk gebruik van de systeemfaciliteiten konden door een fout in 
één programma vele jobs (nadelig) worden beïnvloed. 
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Denk bijvoorbeeld aan de eerste residente monitor, die alleen maar voorzag 
in automatische achtereenvolgende verwerking (zie paragraaf 1.3). Stel dat een 
programma vastloopt in een lus bij het inlezen van invoerkaarten. Het program- 
ma leest dan al de eigen gegevens en, tenzij het ergens door gestopt wordt, aan- 
sluitend de kaarten van de volgende job, en de daaropvolgende, enzovoort. Dit 
zou de correcte verwerking van vele jobs kunnen verhinderen. 

Er zouden in een multiprogrammeringssysteem zelfs subtielere fouten op 
kunnen treden, waar één foutief programma een ander programma of de gege- 
vens ervan, of zelfs de residente monitor zelf, zou kunnen wijzigen. 

Zonder beveiliging tegen dit soort fouten moet óf op de computer één job 
tegelijk draaien, óf moet alle uitvoer onder verdenking staan. Een goed ontwor- 
pen besturingssysteem moet de zekerheid geven dat een incorrect (of kwaadwil- 
lig) programma er niet de oorzaak van kan zijn dat andere programma's niet 
correct worden uitgevoerd. 

Vele programmeringsfouten worden ontdekt door de apparatuur. Deze fou- 
ten worden normaal gesproken behandeld door de residente monitor. Als een 
gebruikersprogramma in zekere opzichten foutief werkt, zoals door een illegale 
instructie of een foutief geheugenadres, loopt de apparatuur in de ‘val’ van de 
residente monitor. (Een ’val’, in het Engels: ’trap’, is een intern ingreepsignaal, 
gewoonlijk het gevolg van een programmafout.) De ’val’, werkend als een onder- 
breking, bergt de programmateller behorend bij de foutieve instructie op en gaat 
dan naar een functieroutine in de residente monitor. Meestal maakt de residente 
monitor automatisch een dump van het geheugen en de registers, alvorens verder 
te gaan met de volgende job. 

Deze benadering werkt goed zolang de fout wordt ontdekt door de appara- 
tuur. We moeten er echter zeker van zijn dat alle fouten worden ontdekt. We 
moeten het besturingssysteem en alle andere programma’s en hun gegevens bevei- 
ligen tegen elk programma dat niet goed functioneert. Beveiliging is nodig voor 
iedere systeemfaciliteit waarvan gemeenschappelijk gebruik wordt gemaakt. 
Daarom zijn er ten minste drie vormen van beveiliging nodig: 1/O-beveiliging, 
geheugenbeveiliging en CVE-beveiliging. 


1.8.1 I/O-beveiliging 


Neem een programma dat invoergegevens probeert te lezen voorbij het einde van 
zijn eigen invoergegevens. Hoe kunnen we dit programma stoppen? Eén manier 
is de gemeenschappelijke 1/O-subroutine te gebruiken die we eerder vermeldden: 
het stuurprogramma (zie paragraaf 1.2). Het stuurprogramma voor de kaartlezer 
zou men zó kunnen wijzigen dat het een poging om een besturingskaart te lezen 
kan ontdekken. Elke kaart die wordt gelezen wordt onderzocht om te zien of het 
een besturingskaart is (dollar-teken in kolom 1 bijvoorbeeld). Zo niet, dan wor- 
den de kaart en de besturing (terug)gegeven aan het gebruikersprogramma, zoals 
gewoonlijk. Als evenwel een poging wordt gedaan om een besturingskaart te le- 
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zen, dan draagt het stuurprogramma voor de kaartlezer de besturing direct over 
aan de residente monitor. De residente monitor behandelt deze situatie dan als 
een fout, maakt een geheugendump en gaat verder naar de volgende job. 

Deze opzet werkt prima, behalve in het geval dat de gebruiker het stuurpro- 
gramma voor de kaartlezer niet gebruikt! Het gebruik van deze gemeenschappe- 
lijke I/O-subroutines is vrijwillig, en er kunnen gevallen zijn waarin program- 
meurs besluiten ze niet te gebruiken maar hun eigen subroutines te schrijven. Zij 
kunnen bijvoorbeeld iets aan de snelheid willen doen en denken dat zij een betere 
manier van buffering kunnen programmeren, of misschien denken ze gewoon dat 
het interessant is hun eigen stuurprogramma te schrijven. 

Om goede service te verlenen mogen we het echter niet zover laten komen. 
Tenzij we kunnen voorkomen dat het ene gebruikersprogramma de besturings- 
kaarten leest van de job van een andere gebruiker (hetzij per ongeluk, hetzij met 
opzet), kunnen we niet garanderen dat elke job correct wordt uitgevoerd. Let 
erop dat dit probleem zich niet voordeed toen iedere job apart gedraaid werd. 
We moeten voorkomen dat ook maar één gebruiker besturingskaarten gaat lezen: 
alleen de monitor mag besturingskaarten lezen. 

We willen dat de computer het besturingssysteem toestaat besturingskaar- 
ten te lezen, maar elk gebruikersprogramma belet dit te doen. Dus willen we dat 
de computer zich anders gedraagt tegenover gebruikersprogramma’s dan tegen- 
over het besturingssysteem. We willen twee verschillende werkwijzen of manieren 
van verwerking: gebruiker-modus en monitor-modus (ook supervisie-modus of sys- 
teem-modus genoemd). Er wordt een bit aan de apparatuur toegevoegd om de op 
elk moment geldende modus aan te geven: monitor (0) of gebruiker (1). 

We stellen nu per definitie vast dat alle I/O-instructies bevoorrechte instruc- 
ties zijn. De apparatuur staat de uitvoering van bevoorrechte instructies alleen toe 
in de monitor-modus. Als een poging wordt gedaan een bevoorrechte instructie in 
de gebruiker-modus uit te voeren, voert de apparatuur deze niet uit, maar behan- 
delt deze als een illegale instructie, die dan in de ’val’ van de residente monitor 
loopt. Altijd wanneer een ’val’ of onderbreking plaatsvindt, schakelt de appara- 
tuur over van de gebruiker-modus op de monitor-modus (dat wil zeggen dat de 
modus-bit op 0 gezet wordt). Dus altijd wanneer de monitor de besturing van de 
computer krijgt, is de computer in de monitor-modus. De monitor schakelt altijd 
over op de gebruiker-modus (door de modus-bit op 1 te zetten) alvorens de bestu- 
ring over te geven aan een gebruikersprogramma. 

Dit werken met een dubbele modus geeft ons de zekerheid dat alleen de 
stuurprogramma’s voor de randapparatuur (die deel uitmaken van de residente 
monitor en derhalve in de monitor-modus worden uitgevoerd) kaarten kunnen 
lezen. Een gebruikersprogramma kan daarom nooit als invoergegevens een bestu- 
ringskaart lezen. 

De werking van de computer is nu heel eenvoudig. We beginnen in de moni- 
tor-modus in de residente monitor. De residente monitor leest de eerste bestu- 
ringskaart en het gewenste programma wordt in het geheugen geladen. Dan geeft 
de monitor, waarbij hij overschakelt van de monitor-modus op de gebruiker- 


Hoofdstuk 1 Inleiding 


modus (een bevoorrechte instructie), de besturing over aan het zojuist geladen 
programma. Wanneer het programma eindigt, geeft het de besturing terug aan 
de monitor, die verder gaat met de volgende besturingskaart. Het gebruikerspro- 
gramma kan geen besturingskaart als invoergegevens inlezen, omdat het gebrui- 
kersprogramma wordt uitgevoerd in de gebruiker-modus en niet rechtstreeks een 
I/O-instructie kan uitvoeren. 

Omdat de I/O-instructies bevoorrecht zijn kunnen ze alleen worden uitge- 
voerd door het besturingssysteem. Hoe kan het gebruikersprogramma dan de 
I/O uitvoeren? Door de 1/O-instructies bevoorrecht te maken hebben we verhin- 
derd dat gebruikersprogramma’s I/O doen, of deze I/O nu geldig is of ongeldig. 
De oplossing voor dit probleem is dat, aangezien alleen de monitor de I/O kan 
doen, de gebruiker aan de monitor moet vragen voor hem de I/O te verzorgen. 

De meeste moderne computers hebben een speciale instructie die monitor- 
aanroep of systeemaanroep wordt genoemd. Op het IBM 370 systeem is het de 
SVC-instructie, op de DEC-10 de UUO-instructie; op de PDP-11 is het de 
TRAP-instructie. Laten we voor al deze termen de uitdrukking systeemaanroep 
gebruiken. Wanneer een systeemaanroep wordt uitgevoerd, wordt deze door de 
apparatuur behandeld als een onderbreking veroorzaakt door de programmatuur. 
De besturing wordt door de onderbrekingsvector overgedragen aan een functie- 
routine in de residente monitor. De bit voor monitor/gebruiker-modus wordt op 
monitor-modus gezet. De functieroutine voor de systeemaanroep is onderdeel 
van de residente monitor. De monitor onderzoekt de instructie die de onder- 
breking veroorzaakte om vast te stellen dat er een systeemaanroep heeft plaats- 
gevonden. Een parameter geeft precies aan wat het verzoek van het gebruikers- 
programma inhoudt. Extra informatie nodig voor het verzoek kan worden door- 
gegeven in registers of in het geheugen (waarbij wijzers naar de geheugenplaatsen 
in registers zijn gezet). De monitor voert het verzoek uit en geeft de besturing 
terug aan de instructie die volgt op die van de systeemaanroep. 

Aldus voert een gebruikersprogramma voor het doen van I/O een systeem- 
aanroep uit om de monitor (van het besturingssysteem) te verzoeken voor hem 
I/O te verzorgen (zie figuur 1.8). 

De monitor van het besturingssysteem, die draait in de monitor-modus, 
gaat na of het verzoek geldig is, en voert (als dat zo is) de gevraagde I/O uit. De 
monitor geeft dan de besturing terug aan de gebruiker. 

De methode van de dubbele modus geeft het besturingssysteem de mo- 
gelijkheid te allen tijde het volledige beheer over het computersysteem te behou- 
den. Gebruikersprogramma’s kunnen niet rechtstreeks een of andere I/O uitvoe- 
ren die de correcte werking van het systeem in gevaar zou kunnen brengen. Zij 
moeten de hulp van de monitor van het besturingssysteem inroepen. De monitor 
gaat altijd eerst na of het verzoek redelijk is en toegestaan voor die gebruiker. Zo 
ja, dan voert de monitor het verzoek voor de gebruiker uit en geeft dan de bestu- 
ring aan de gebruiker terug. Bovendien kan het besturingssysteem, omdat het 
wordt aangeroepen voor elke I/O-bewerking, spool-verwerking toepassen, even- 
als buffering en blokken, om het prestatievermogen te verbeteren. Het kan ook 
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Figuur 1.8 
Gebruik van een systeemaanroep voor het doen van I/O 


de relatie leggen tussen logische en fysieke randapparaten voor apparatuur-onaf- 
hankelijkheid. Derhalve levert I/O gebaseerd op de dubbele modus zowel 1/0- 
beveiliging als mogelijke verbetering in het prestatievermogen. 


1.8.2 Geheugenbeveiliging 


Voor volledige I/O-beveiliging moeten we er zeker van zijn dat een gebruikers- 
programma nooit de besturing van de computer zal kunnen krijgen in de moni- 
tor-modus. Als de computer draait in de gebruiker-modus zal hij, steeds wanneer 
een onderbreking of ’val’ optreedt, overschakelen op de monitor-modus, waarbij 
hij naar het adres springt dat bepaald is -door de onderbrekingsvector. Stel nu 
dat een gebruikersprogramma, als onderdeel van zijn verwerking, een nieuw adres 
in de onderbrekingsvector zet. Dit nieuwe adres zou het vorige adres van de on- 
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derbrekingsfunctieroutine kunnen overschrijven met een adres in het gebruikers- 
programma. Dan zou de apparatuur, op het moment dat er een daarbij behorende 
onderbreking of ’val’ plaatsvindt, overschakelen op de monitor-modus en via de 
(gewijzigde) onderbrekingsvector de besturing overdragen aan het gebruikerspro- 
gramma! Het gebruikersprogramma zou dan de besturing van de computer krij- 
gen in de monitor-modus. 

We moeten de onderbrekingsvector beveiligen tegen wijziging door een ge- 
bruikersprogramma. Bovendien moeten we ook de onderbrekingsfunctieroutines 
in de residente monitor beveiligen tegen wijziging. Anders zou een gebruikerspro- 
gramma instructies in de onderbrekingsfunctieroutine kunnen overschrijven met 
sprong-instructies naar het gebruikersprogramma, waardoor dit de besturing 
krijgt van de onderbrekingsfunctieroutine die draait in de monitor-modus. Zelfs 
al kreeg de gebruiker niet de ongeautoriseerde besturing van de computer, het 
modificeren van de onderbrekingsfunctieroutines zou waarschijnlijk de juiste 
werking van het computersysteem met zijn spool-verwerking en buffering teniet- 
doen. 

We zien dus dat we het geheugen moeten beveiligen, althans voor wat de 
onderbrekingsvector en de onderbrekingsfunctieroutines van de residente mo- 
nitor betreft. Een soortgelijke redenering toont aan dat deze geheugenbeveiliging 
moet worden verzorgd door de apparatuur. In de praktijk kan dit op verschillen- 
de manieren worden gedaan, zoals we zullen zien in hoofdstuk 5. 

In de meeste gevallen bezetten zowel de onderbrekingsvector als de residen- 
te monitor de lage adressen in het geheugen, terwijl gebruikersprogramma’s ge- 
laden worden in het hoge-adresgedeelte. Geheugenbeveiliging kan dan een simpel 
*hek’register zijn, dat het geheugen in twee delen scheidt: het gebruikers- en het 
monitorgedeelte (zie figuur 1.9). Het monitor-geheugen mag niet geadresseerd of 
gewijzigd worden in de gebruiker-modus. Deze beveiliging wordt gerealiseerd 
door ieder adres dat in de gebruiker-modus gegenereerd wordt te vergelijken met 
het hekregister. Iedere poging van een gebruikersprogramma om het monitor- 
geheugen te adresseren heeft tot gevolg dat het programma in de ’val’ van de 
monitor loopt, die dan de poging behandelt als een fatale fout. Dit voorkomt dat 
het gebruikersprogramma (per ongeluk of moedwillig) de code of gegevensstruc- 
turen van de residente monitor wijzigt. 

Het hekregister kan worden geladen door het besturingssysteem, door ge- 
bruik te maken van een speciale bevoorrechte instructie. Daar bevoorrechte in- 
structies alleen kunnen worden uitgevoerd in de monitor-modus, en alleen het 
besturingssysteem in de monitor-modus draait, kan alleen het besturingssysteem 
het hekregister laden. Deze opzet geeft de monitor de mogelijkheid iedere keer 
dat de grootte van de monitor verandert de waarde van het hekregister te wij- 
zigen, maar voorkomt dat gebruikersprogramma’s de inhoud van het hekregister 

wijzigen. 

Het besturingsysteem, draaiend in de monitor-modus, krijgt in het alge- 
meen onbeperkt toegang tot zowel het monitor- als het gebruikersgeheugen. Zo 
wordt ervoor gezorgd dat het besturingssysteem gebruikersprogramma’s in het 
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Figuur 1.9 
Residente monitor-geheugenbeveiliging door de apparatuur 


gebruikersgeheugen kan laden, er in geval van fouten een dump van kan maken, 
toegang heeft tot parameters van systeemaanroepen en deze kan wijzigen, enzo- 
voort. 

Mischien heeft u opgemerkt dat, hoewel een simpel hekregister voldoende 
is om de onderbrekingsvector en de residente monitor tegen wijziging te bevei- 
ligen, het in het algemeen niet voldoende is om gebruikersprogramma’s tegen 
elkaar te beveiligen. Bekijk ter illustratie het systeem in figuur 1.6. Stel dat pro- 
gramma 3 in uitvoering is. We zouden het hekregister kunnen opschuiven zodat 
het wijst naar het begin van programma 3 (zie figuur 1.10). 

Dit-garandeert dat programma 3 geen toegang heeft tot geheugenposities 
in de residente monitor, of in programma 1 of programma 2. Het beveiligt echter 
andere gebruikers (zoals programma 4) niet tegen ongeautoriseerde toegang door 
programma 3. 

Wat we nodig hebben is een faciliteit om de geheugenruimte voor en achter 
een programma in uitvoering te beveiligen. Deze beveiliging kan worden gereali- 
seerd door twee registers te gebruiken, zoals figuur 1.11 laat zien. Deze registers 
geven de boven- en ondergrenzen aan van de adressen die legaal door een gebrui- 
kersprogramma kunnen worden gegenereerd. Dat wil zeggen: de grensregisters 
bevatten de waarden van de kleinste en grootste fysieke adressen (bijvoorbeeld 
ondergrens = 100040 en bovengrens = 174640) die door een individueel pro- 
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hekregister 


Figuur 1.10 
We kunnen proberen de uitvoering van het programma mogelijk te maken door het hek te 
verschuiven 


gramma kunnen worden gegenereerd. Andere mechanismen voor geheugenbevei- 
liging worden besproken in hoofdstuk 5. 

Instructies voor het wijzigen van de inhoud van registers voor geheugen- 
beheer, zoals hek- of grensregisters, moeten natuurlijk bevoorrechte instructies 
zijn. Alleen het besturingssysteem mag in staat zijn deze registers te wijzigen. 


1.8.3 CVE-beveiliging 


Een laatste toevoeging in de architectuur van het computersysteem is de toevoe- 
ging van een tijdregister. Een tijdregister voorkomt dat een gebruikersprogramma 
vast komt te zitten in een oneindige lus en nooit de besturing aan de monitor 
teruggeeft. Een tijdregister kan worden gezet als een soort wekker die na een 
zekere tijd afloopt en een onderbreking in de computer veroorzaakt. Deze periode 
kan vast zijn (bijvoorbeeld 1/60 seconde) of variabel (bijvoorbeeld vanaf 1 mil- 
liseconde tot 1 seconde in stapjes van 1 miliseconde). Een variabele-tijdregister 
wordt in het algemeen in de praktijk gerealiseerd door middel van een klok met 
vaste snelheid en een teller. Het besturingssysteem zet de teller. ledere keer dat 
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Figuur 1.11 
Twee grensregisters definiëren een logische adresruimte 


de klok tikt, wordt de teller verlaagd. Wanneer de teller op nul komt vindt een 
onderbreking plaats. Een teller van 10 bits met een 1-milliseconde-klok maakt 
onderbrekingen mogelijk met tussenpozen van 1 milliseconde tot 1024 millise- 
conden, met stapjes van 1 milliseconde. 

Alvorens de besturing aan de gebruiker te geven, gaat de monitor na of de 
wekker is gezet om een onderbreking te veroorzaken. Zodra dit gebeurt wordt de 
besturing automatisch aan de monitor gegeven, die dit als een fatale fout kan 
beschouwen of kan beslissen het programma meer tijd te geven. Instructies die 
de werking van het tijdregister wijzigen zijn uiteraard bevoorrecht. 


1.8.4 De uiteindelijke architectuur 


De wens de opsteltijd terug te brengen en de gebruiksfactor van de computer 
op te voeren leidde tot groepsgewijze verwerking van jobs, bufferen en spool- 
verwerking en uiteindelijk tot multiprogrammering en tijddeling. Deze benade- 
ringen geven vele verschillende programma’s en jobs het gemeenschappelijk ge- 
bruik van computersysteemfaciliteiten. Dit leidde rechtstreeks tot wijzigingen in 
de basis-computerarchitectuur, om de besturing van de computer, en vooral de 
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in- en uitvoer, aan de monitor over te laten. De besturing moet worden gehand- 
haafd, willen we zorg kunnen dragen voor een continue, consequente en correcte 
werking. 

Om de besturing in handen te houden werd een dubbele verwerkingsmodus 
(gebruiker-modus en monitor-modus) ingevoerd. Deze opzet ondersteunt het idee 
van bevoorrechte instructies, die alleen in de monitor-modus kunnen worden 
uitgevoerd. De I/O-instructies en instructies voor het wijzigen van de registers 
voor geheugenbeheer, of het tijdregister, zijn bevoorrechte instructies. 

Zoals u zich kunt voorstellen zijn verscheidene andere instructies ook als 
bevoorrechte instructies geclassificeerd. De HALT-instructie bijvoorbeeld is be- 
voorrecht; een gebruikersprogramma mag nooit in staat zijn de computer stop te 
zetten (HALT). De instructies voor het aan- en afzetten van het onderbrekings- 
systeem zijn ook bevoorrecht, omdat de juiste werking van het tijdregister en van 
de I/O afhangt van het vermogen correct op onderbrekingen te reageren. De 
instructie voor het overschakelen van de gebruiker-modus op de monitor-modus 
is bevoorrecht, en op vele machines is elke wijziging van de bit voor gebruiker / 
monitor-modus bevoorrecht. 

Geheugenbeveiliging moet er zijn voor de monitor en de onderbrekingsvec- 
tor, alsook voor gebruikersprogramma’s en -gegevens. Het gebruikersprogramma 
wordt door het besturingssysteem in zijn werking beperkt om te voorkomen dat 
het de juiste werking van de computer ontwricht (zie figuur 1.12). 

Men moet zich voor ogen houden dat het primaire doel van buffering, 
spool-verwerking, multiprogrammering en tijddeling het prestatievermogen is. We 
willen maximaal profijt trekken uit het computersysteem. Het besturingssysteem 
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Figuur 1.12 
Het besturingssysteem beperkt het gebruikersprogramma 
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moet, naast het zorgen voor van een gemakkelijke werkomgeving waarin de ge- 
bruiker programma’s kan schrijven en draaien, ook steeds meer de verantwoorde- 
lijkheid op zich nemen voor het regelen van het efficiënte gebruik van de CVE en 
zijn randapparatuur. Deze tendens van het opvoeren van de CVE-gebruiksfactor 
(plus de veranderingen in de technologie) brachten ingrijpende veranderingen 
teweeg in de omgeving die het besturingssysteem voor de programmeur had ge- 
creëerd. 

De veranderingen in de computerarchitectuur die we zojuist hebben be- 
sproken leveren de mechanismen die nodig zijn om te garanderen dat een bestu- 
ringssysteem correct functioneert. Een systeemontwerper kan er zeker van zijn 
dat geen enkel gebruikersprogramma de werking van de computer kan ontwrich- 
ten (tenzij er natuurlijk fouten zijn in het besturingssysteem). 


1.9 Verschillende categorieën computers 


Het grootste gedeelte van onze bespreking tot nu toe heeft betrekking gehad 
op mainframe-computersystemen, de grote standaardcomputersystemen die men 
aantreft in rekencentra en centra voor gegevensverwerking. Het merendeel van 
de theorie en de techniek werd ontwikkeld voor mainframe-computersystemen. 
Mainframe besturingssystemen zijn gedurende de laatste dertig jaar ontwikkeld. 

Minicomputers deden hun intrede in het midden van de jaren ’60, en zijn 
aanzienlijk kleiner en minder duur dan mainframe-systemen. Microcomputers 
verschenen in de jaren ’70, en zijn nog weer kleiner en goedkoper. De besturings- 
systemen voor deze computers hebben op verschillende manieren geprofiteerd 
van de ontwikkeling van de besturingssystemen voor mainframes. Minicom- 
puters en microcomputers konden de techniek die ontwikkeld was voor grotere 
besturingssystemen onmiddellijk overnemen. Op deze wijze konden zij de vergis- 
singen die gemaakt waren door de prototype-besturingssystemen voor main- 
frames vermijden. De meeste mini- en micrcomputersystemen hebben systemen 
voor groepsgewijze verwerking vermeden en zijn meteen op interactieve systemen 
en systemen met tijddeling overgegaan. 

Aan de andere kant zijn de kosten van de apparatuur voor minicomputers 
en microcomputers zo laag dat het misschien niet nodig is dat meerdere gebrui- 
kers de apparatuur gebruiken om een hoge CVE-gebruiksfactor te halen. Zo zijn 
sommige beslissingen inzake het ontwerp van besturingssystemen voor main- 
frames wellicht niet geschikt voor kleinere systemen. 

In het algemeen echter blijkt uit een onderzoek van besturingssystemen 
voor mainframes, minicomputers en microcomputers dat voorzieningen die ooit 
alleen op mainframes beschikbaar waren, door minicomputers werden overge- 
nomen. De voorzieningen op minicomputers werden ook op microcomputers ge- 
introduceerd. Dezelfde ideeën en technieken zijn geschikt voor al de verschillende 
computer-categorieën (zie figuur 1.13). 

Een goed voorbeeld van deze verschuiving zien we bij het Multics-bestu- 
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Migratie van besturingssysteemconcepten en -kenmerken 


ringssysteem. Multics werd ontwikkeld tussen 1965 en 1970 op het MIT (Massa- 
chusetts Institute of Technology) als een functieprogramma. Het draaide op een 
zeer grote en complexe mainframe-computer (de GE 645). Vele van de ideeën die 
voor Multics werden ontwikkeld, werden later gebruikt in de Bell Laboratories 
(Bell was één van de oorspronkelijke deelnemers in de ontwikkeling van Multics) 
in het Unix werd rond 1970 ontworpen voor een PDP-11 minicomputer. Rond 
1980 werden de voorzieningen van Unix de basis voor Unix en Unix-achtige 
besturingssystemen op microcomputers. De voorzieningen ontwikkeld voor een 
groot mainframe-systeem hebben dus mettertijd een verschuiving te zien gegeven 
in de richting van de mini- en microcomputers. 

Er zijn stemmen opgegaan dat de ontwikkeling van goedkope microproces- 
soren en goedkoop geheugen, besturingssystemen (en cursussen waarin deze wor- 
den behandeld) zal doen verdwijnen. Wij geloven niet dat dit waar is. Eerder 
maakt het goedkoper worden van de apparatuur het mogelijk dat betrekkelijk 
hoogontwikkelde denkbeelden op het gebied van besturingssystemen (zoals tijd- 
deling en virtueel geheugen) op een nog groter aantal systemen worden geïmple- 
menteerd. De verschuiving van eenvoudige besturingssystemen (zoals CP/M) 
naar multiprogrammeringsystemen (zoals MP/M of Unix) ondersteunt deze op- 
vatting. 
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Zo zal het goedkoper worden van computerapparatuur, zoals microproces- 
soren, de behoefte om de ideeën aangaande besturingssystemen te begrijpen doen 
toenemen. 


1.10 Multiprocessor-systemen 


Er zijn verschillende pogingen ondernomen om systemen te creëren met meerdere 
verwerkingseenheden: multiprocessor-systemen. Het standaardsysteem is het uni- 
processor-systeem, dat wil zeggen dat het één centrale verwerkingseenheid heeft. 
Een echt multiprocessor-systeem heeft meer dan één CVE, waarbij de CVE’s 
gemeenschappelijk gebruik maken van het geheugen en de randapparatuur. Men 
zou denken dat dit klaarblijkelijk het voordeel heeft van een grotere computer- 
capaciteit en betrouwbaarheid. Het is echter nog niet bekend hoe een volledig 
algemeen multiprocessor-besturingssysteem moet worden gemaakt. Meestal ge- 
bruikt men één van de volgende twee benaderingen. 

De meest gangbare multiprocessor-besturingssystemen kennen aan elke 
processor een specifieke taak toe. Een hoofdprocessor, de ’meester’, bestuurt het 
systeem; de andere processoren vragen óf aan de meester wat ze moeten doen óf 
ze hebben van tevoren vastgestelde taken. Dit ontwerp definieert een meester / 
slaaf-verhouding. In het bijzonder kunnen kleine processoren, die op enige af- 
stand van de hoofdprocessor zijn opgesteld, worden gebruikt om kaartlezers en 
regeldrukkers te besturen en de bijbehorende jobs naar en van de hoofdcomputer 
over te brengen. De plaatsen waar deze CVE’s staan opgesteld noemt men Re- 
mote Job Entry locaties (RJE; jobinvoer op afstand). Systemen met tijddeling 
bestaan dikwijls uit een grote computer (zoals een DEC-20), de hoofdcomputer, 
en een kleinere front-end-computer (zoals een PDP-11) die alleen verantwoorde- 
lijk is voor alle in- en uitvoer via de terminal. 

Het tweede vrij gangbare multiprocessor-systeem is een computernetwerk. 
In een netwerk kunnen meerdere onafhankelijke computersystemen met elkaar 
communiceren, waarbij bestanden en informatie over en weer worden gestuurd. 
leder computersysteem heeft evenwel zijn eigen besturingssysteem en werkt onaf- 
hankelijk. Computernetwerken bieden nieuwe mogelijkheden voor gedistribueer- 
de verwerking, zoals wordt besproken in hoofdstuk 13. 


1.11 Samenvatting 


Twee hoofddoeleinden hebben de ontwikkeling van besturingssystemen in de af- 
gelopen dertig jaar bepaald. Ten eerste leveren ze een gemakkelijke omgeving 
voor het ontwikkelen en uitvoeren van programma’s. Ten tweede proberen bestu- 
ringssystemen de werkzaamheden binnen de computer in te delen, om een goed 
prestatievermogen van het computersysteem te verzekeren. 

In het begin werden computers gebruikt vanaf het bedieningspaneel. Pro- 
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grammatuur zoals assembleerprogramma’s, laadprogramma’s en compileerpro- 
gramma’s, brachten verbetering in het gemak waarmee het systeem geprogram- 
meerd wordt, maar vereisten ook een aanzienlijke opstellingstijd. Om deze opstel- 
lingstijd te bekorten werden operateurs aangenomen en werden gelijksoortige 
jobs tot groepjes (batches) samengevoegd. 

Systemen voor groepsgewijze verwerking brachten de mogelijkheid van het 
automatisch achtereenvolgens verwerken van jobs met behulp van een residente 
monitor en droegen aanzienlijk bij tot een hogere gebruiksfactor van de compu- 
ter. De computer hoefde niet langer te wachten op menselijke handelingen. De 
CVE-gebruiksfactor was evenwel nog steeds laag, vanwege de traagheid van de 
randapparatuur in vergelijking met de CVE. Men beproefde niet-gekoppelde 
(off-line) werking van langzame apparatuur. Buffering was een andere aanpak 
om het prestatievermogen van het systeem op te voeren, door het overlappen van 
invoer, uitvoer en de verwerking van één enkele job. Tenslotte gaf spool-verwer- 
king de CVE de mogelijkheid de invoer van één job te overlappen met de verwer- 
king en de uitvoer van andere jobs. 

Spool-verwerking levert ook een jobpot, waarin de jobs zijn ingelezen en 
staan te wachten om gedraaid te worden. Deze jobpot is in overeenstemming met 
het idee van multiprogrammering. Bij multiprogrammering worden diverse jobs 
tegelijk in het geheugen gehouden; de CVE wordt van de ene op de andere job 
overgeschakeld om de CVE-gebruiksfactor te verhogen en de totale tijd nodig 
voor het uitvoeren van een job terug te brengen. 

Multiprogrammering, dat werd ontwikkeld om het prestatievermogen te 
verhogen, maakt ook tijddeling mogelijk. Besturingssystemen met tijddeling ge- 
ven vele gebruikers (van één tot enkele honderden) de gelegenheid een computer- 
systeem gelijktijdig interactief te gebruiken. Andere soorten besturingssystemen 
zijn bijvoorbeeld onvertraagde (real-time) en multiprocessor-systemen. 

Het besturingssysteem moet borg staan voor de correcte werking van het 
computersysteem. Om gebruikersprogramma’s te verhinderen in de juiste wer- 
king van het systeem in te grijpen werd de apparatuur gewijzigd om twee manie- 
ren van verwerking te creëren: de gebruiker-modus en de monitor-modus. Diver- 
se instructies (zoals 1/O-instructies en HALT-instructies) zijn bevoorrecht en 
kunnen alleen worden uitgevoerd in de monitor-modus. Het geheugen waarin de 
monitor verblijft moet eveneens worden beveiligd tegen wijziging door de gebrui- 
ker. Een tijdregister voorkomt oneindige lussen. Zijn deze veranderingen (dub- 
bele modus, bevoorrechte instructies, geheugenbeveiliging, onderbreking door 
het tijdregister) eenmaal in de basis-computerarchitectuur aangebracht, dan is 
het mogelijk een correct werkend besturingssysteem te schrijven. 

Besturingssysteemtechnieken laten een neerwaartse migratie zien van de 
mainframes naar de mini- en microcomputersystemen. 
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Opgaven 


1.1 Wat zijn de hoofddoeleinden van een besturingssysteem? 


1.2 Schrijf alle stappen op die nodig zijn om een programma op een volledig 
voor dat programma bestemde machine te draaien. 


1.3 Welke van de volgende instructies zijn bevoorrecht? 
a. Zet waarde tijdregister. 
b. Lees de klok. 
c. Wis het geheugen. 
d. Zet onderbrekingen af. 
e. Schakel over van de gebruiker- op de monitor-modus. 


1.4 Het schrijven van een besturingssysteem dat kan werken zonder inmen- 
ging van kwaadbedoelende of niet foutvrij gemaakte programma’s, ver- 
eist enige assistentie van de apparatuur. Noem drie vormen van hulp 
door de apparatuur bij het schrijven van een besturingssysteem. 


1.5 Het idee van multiprogrammering was niet bruikbaar (dat wil zeggen 
dat het niet kon worden gebruikt om betere prestaties van een computer- 
systeem af te dwingen) totdat het kanaal voor directe toegang tot het 
geheugen (DGT kanaal) werd ontwikkeld. Verklaar waarom. 


1.6 In een multiprogrammerings- en tijddelingsomgeving maken diverse ge- 
bruikers gelijktijdig gebruik van het systeem. Dit leidt tot een bevei- 
ligingsprobleem. 

a. Schrijf verschillende van zulke problemen op. 

b. Kunnen we dezelfde mate van beveiliging garanderen voor een ma- 
chine die gemeenschappelijk gebruikt wordt als voor een machine waar- 
voor dat niet het geval is? 


1.7 Laat zien hoe de wens om gebruik te maken van besturingskaarten van- 
zelf tot een afzonderlijke gebruiker/monitor-modus leidt. 


1.8 Hoe functioneert het onderscheid tussen monitor- en gebruiker-modus 
als een elementair beveiligingssysteem? 


1.9 Enkele van de eerste computers beveiligden het besturingssysteem door 
het in een geheugenpartitie te plaatsen die niet kon worden gemodi- 
ficeerd door het gebruikersprogramma, noch door het besturingssysteem 
zelf. Wat voor moeilijkheden kunnen in zo’n ontwerp ontstaan? 


1.10 Veel computersystemen hebben geen gebruiker/monitor-modus in de 
apparatuur. Betekent dit dat het niet mogelijk is een besturingssysteem 
voor zulke computers te bouwen? Geef zowel een argument vóór als een 
argument tegen de vraagstelling. 


1.11 


1.12 


1.13 


1.14 
1.15 


1.16 
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Het beveiligen van de residente monitor is essentieel voor het correct 
werken van een besturingssysteem. Het geven van deze beveiliging is de 
reden voor het systeem van de dubbele modus, geheugenbeveiliging, en 
het tijdregister. Voor een maximale flexibiliteit zouden we echter tevens 
minimale beperkingen willen opleggen aan de gebruiker. Nu volgt een 
lijst van bewerkingen die normaal gesproken beveiligd zijn. Wat is de 
minimale groep instructies die moet worden beveiligd? 

Schakel over op de gebruiker-modus. 

. Schakel over op de monitor-modus. 

Lees uit het monitor-geheugengedeelte. 

. Schrijf in het monitor-geheugengedeelte. 

Haal instructie op uit het monitor-geheugengedeelte. 

Zet onderbreking door het tijdregister aan. 

Zet onderbreking door het tijdregister af. 


Pma 


Definieer de essentiële verschillen tussen de volgende soorten bestu- 
ringssystemen: 

a. Groepsgewijze verwerking. 

b. Interactief. 

c. Tijddeling. 

d. Onvertraagd. 


Wat zijn de voornaamste moeilijkheden bij het schrijven van een bestu- 
ringssysteem voor een onvertraagde omgeving? 


Wat zijn de voornaamste voordelen van multiprogrammering? 


Eén van de nadelen van de eerste besturingssystemen (bijvoorbeeld sys- 
temen voor groepsgewijze verwerking) was dat gebruikers de mogelijk- 
heid tot interactie met hun jobs kwijtraakten. Op welke manieren lossen 
moderne besturingssystemen dit probleem op? 


Waarom is spool-verwerking noodzakelijk voor groepsgewijze multipro- 
grammering? Is dit nodig voor een systeem met tijddeling? 


Bibliografische verwijzingen 


Algemene overzichten van de functies en begrippen aangaande besturingssys- 
temen worden gegeven door Warwick [1970], Hoare [1972a], Tsichritzis en Bern- 
stein [1974, hoofdstuk 1], Lister [1979, hoofdstuk 2] en Habermann [1976, para- 
graaf 1.2]. Besprekingen over de historische evolutie van computerapparatuur 
en programmatuursystemen worden gegeven door Rosen [1969], Rosin [1969], 
Denning [1971], Sayers [1971, hoofdstukken 7, 8 en 9], Shaw [1974, paragraaf 1.3] 
en Weizer [1981]. 

Een van de eerste systemen voor groepsgewijze verwerking wordt beschre- 
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ven door Bratman en Boldt [1959]. Een overzicht van een eenvoudig besturings- 
systeem voor groepsgewijze verwerking vindt men in Graham [1975, hoofdstuk 
2]. Algemene besprekingen met betrekking tot systemen voor groepsgewijze ver- 
werking worden gegeven door Kurzban et al. [1975, paragrafen 1.2 en 1.3]. Job- 
besturingstalen worden besproken door Brown [1970], Barron [1974] en Frank 
[1976]. 

Niet-gekoppelde systemen (satellietverwerking) werden gebruikt door het 
IBM Fortran Monitor System van het eind van de jaren ’50 tot het midden van 
de jaren ’60. Pionierswerk in verband met spool-verwerking werd verricht op het 
Atlas-computersysteem aan de Universiteit van Manchester [Kilburn et al. 1961]. 
Spool-verwerking werd ook gebruikt op het Univac EXEC II systeem [Lynch 
1967, 1972a]. 

Systemen met tijddeling werden voor het eerst te berde gebracht door Stra- 
chey [1959]. De voordelen van een gekoppelde interactie tussen mens en machine 
werden later besproken door Licklider en Clark [1962]. De eerste systemen met 
tijddeling waren het CTSS-systeem, ontwikkeld op het MIT [Corbato et al. 1962], 
en het SDC Q-32 systeem dat gebouwd werd door de System Development Cor- 
poration [Schwartz et al. 1964, Schwartz en Weissman 1967]. Andere oudere, 
maar hoger ontwikkelde systemen zijn onder meer het Multics-systeem, ontwik- 
keld op het MIT [Corbato en Vyssotsky 1965], het XDS-940 systeem, ontwikkeld 
aan de Universiteit van Californië te Berkeley [Lichtenberger en Pirtle 1965], en 
het IBM TSS/360 systeem [Lett en Konigsford 1968]. Algemene besprekingen 
over systemen met tijddeling worden gegeven door Watson [1970, paragrafen 1.1 
tot 1.4] en Graham [1975, hoofdstuk 13]. 

Stone [1980] betoogde dat de ontwikkeling van goedkope microprocessoren 
en goedkoop geheugen, besturingssystemen en cursussen die daarop betrekking 
hebben overbodig zullen maken. Denning [1980b, 1982a] gaf als repliek dat de 
fundamentele oude denkbeelden betreffende besturingssystemen eenvoudig wor- 
den verfijnd en dat er op de hedendaagse apparatuur nuttig gebruik van gemaakt 
wordt. 

Algemene besprekingen over multiprocessor-systemen worden gegeven 
door Nutt [1977], Enslow [1977], Gula [1978], en Jones en Schwarz [1980]. Multi- 
processor-apparatuur wordt besproken door Satyanarayanan [1980a, 1980b]. Een 
overzicht van computernetwerken wordt gegeven door Kimbleton en Schneider 
[1975] en Forsdick et al. [1978]. 


2 


FUNCTIES VAN 
BESTURINGSSYSTEMEN 


Een besturingssysteem verschaft de werkomgeving waarin programma’s worden 
uitgevoerd. Aangezien alleen het besturingssysteem de eigenlijke in- en uitvoer- 
bewerkingen kan verrichten, moeten gebruikersprogramma’s het besturingssys- 
teem verzoeken al dergelijke operaties te doen. In dit hoofdstuk gaan we na welke 
functies een besturingssysteem verricht en hoe deze worden verricht. 


2.1 Soorten functies 


Een besturingssysteem verschaft de werkomgeving voor het uitvoeren van pro- 
gramma’s. Het besturingssysteem verricht bepaalde functies voor programma’s 
en voor de gebruikers van die programma’s. De specifieke functies die worden 
verricht zullen natuurlijk van besturingssysteem tot besturingssysteem verschil- 
len, maar er kunnen een paar algemene functie-categorieën worden onderschei- 
den. Deze besturingssysteemfuncties worden verricht voor het gemak van de pro- 
grammeur, om de taak van het programmeren te verlichten. 


e Programma-uitvoering. Gebruikers willen programma’s laten uitvoeren. Het 
systeem moet in staat zijn een programma in het geheugen te laden en het te 
draaien. Het programma moet in staat zijn de uitvoering te beëindigen, op 
normale wijze óf op abnormale wijze. 

@ Invoer/uitvoerbewerkingen. Een lopend programma kan invoer en uitvoer ver- 
eisen. Met deze I/O kan een bestand of een randapparaat gemoeid zijn. Voor 
specifieke randapparatuur kunnen specifieke functies worden verlangd (zoals 
het terugspoelen van een magneetband, het schoonmaken van het scherm op 
een CRT, enzovoort). Aangezien een gebruikersprogramma niet rechtstreeks 
I/O-bewerkingen kan verrichten, moet het besturingssysteem de middelen 
hiervoor bieden. 

@ Bestandsverwerking. Het bestandssysteem is speciaal van belang. Het is duide- 
lijk dat programma’s bestanden willen lezen en er naar schrijven. We willen 
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ook met name te noemen bestanden aanmaken en opheffen. Het bestandssys- 
teem wordt uitvoerig besproken in hoofdstuk 3. 

@ Foutsignalering. Het besturingssysteem moet voortdurend rekening houden 
met mogelijke fouten. Fouten kunnen optreden in de CVE en het geheugen 
(zoals een geheugenfout of een stroomstoring), in de randapparatuur (zoals 
een pariteitsfout op een magneetband, een beschadigde schijf, of het opraken 
van het papier in de printer), of in het gebruikersprogramma (zoals een reken- 
kundige overloop, een poging om toegang te verkrijgen tot een illegale geheu- 
genpositie, of het gebruiken van te veel CVE-tijd). Voor elk type fout moet het 
besturingssysteem de juiste maatregelen treffen om een correcte en consistente 
verwerking te garanderen. 


Daarnaast bestaat er een andere groep systeemfuncties, niet voor de gebrui- 
ker maar ten behoeve van de efficiënte werking van het systeem zelf. Systemen 
met meerdere gebruikers kunnen aan efficiëntie winnen door de gebruikers het 
gemeenschappelijk gebruik van systeemfaciliteiten toe te staan. 


@ Toewijzing van systeemfaciliteiten. Wanneer er meerdere gebruikers zijn, of 
meerdere jobs tegelijkertijd draaien, moeten aan elk daarvan systeemfacilitei- 
ten worden toegewezen. Vele verschillende soorten systeemfaciliteiten worden 
beheerd door het besturingssysteem. Sommige (zoals CVE-cycli, het hoofdge- 
heugen en bestandsopslagruimte) kunnen speciale code voor de toewijzing 
hebben, terwijl andere (zoals randapparatuur) algemenere code kunnen heb- 
ben voor het verkrijgen en weer vrijgeven van systeemfaciliteiten. 

@ Boekhouding. We willen bijhouden hoeveel gebruikers hoeveel en welke soor- 
ten computersysteemfaciliteiten gebruiken. Deze boekhouding kan ten doel 
hebben het gebruik van het systeem en de werking ervan door te berekenen, 
of gewoon het verzamelen van gebruiksstatistieken. Gebruiksstatistieken kun- 
nen een waardevol instrument zijn wanneer we proberen tot een zodanige sys- 
teemconfiguratie te komen dat de dienstverlening van het computersysteem 
wordt verbeterd. E 

@ Beveiliging. De eigenaars van informatie die opgeslagen is in een computersys- 
teem met meerdere gebruikers willen misschien zeggenschap hebben over het 
gebruik daarvan. Wanneer verschillende jobs die niets met elkaar te maken 
hebben gelijktijdig worden uitgevoerd om de gebruiksfactor op te voeren, moet 
het niet mogelijk zijn dat de ene job invloed heeft op de andere jobs. Boven- 
dien moeten met elkaar strijdige verzoeken om allerlei systeemfaciliteiten eer- 
lijk met elkaar in overeenstemming worden gebracht en moet de toewijzing op 
redelijke basis plaatsvinden. 


2.2 Functies gezien vanuit de gebruiker 


Besturingssysteemfuncties worden op tal van manieren verricht. Twee fundamen- 
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tele methoden van dienstverlening zijn systeemaanroepen en systeemprogramma's. 
Elk van beide methoden heeft zijn voordelen. 


2.2.1 Systeemaanroepen 


Het basisniveau van systeemfuncties wordt afgehandeld via het gebruik van sys- 
teemaanroepen (Engels: system calls, supervisor calls, SVC's). Systeemaanroepen 
vormen de koppeling tussen een lopend programma en het besturingssysteem. 
Deze aanroepen zijn algemeen beschikbaar als instructies in de assembleertaal 
en zijn gewoonlijk vermeld in de handboeken die gebruikt worden door assem- 
bleertaal-programmeurs. 

Systeemaanroepen kunnen ruwweg worden ingedeeld in drie hoofdcatego- 
rieén: proces- of job-besturing, randapparatuur-besturing en bestandsbewerking en 
het bijhouden van informatie. In de nu volgende bespreking geven we in het kort 
aan welke soorten systeemaanroepen in een besturingssysteem kunnen voorko- 
men. Helaas kan onze beschrijving enigszins oppervlakkig lijken, omdat op dit 
moment de meeste van die systeemaanroepen ondersteuning geven aan, of onder- 
steund worden door, ideeën en functies die in latere hoofdstukken worden be- 
sproken. 


Proces- en job-besturing 

Een draaiend programma moet in staat zijn zijn uitvoering stop te zetten, hetzij 
op normale wijze (beëindig) hetzij op abnormale wijze (beëindig voortijdig). Als 
het programma een fout in zijn invoergegevens ontdekt en de uitvoering voor- 
tijdig wil beëindigen, wil het misschien ook een foutniveau vaststellen. Ernstiger 
fouten kunnen dan worden aangeduid door een hoger foutniveau. Het is dan 
mogelijk normale en abnormale (voortijdige) beëindiging samen te voegen door 
een normale beëindiging te definiëren als een abnormale beëindiging met niveau 0. 

Een proces of job kan tijdens de uitvoering van een programma een ander 
programma willen laden en uitvoeren. Dit geeft de besturingskaartvertolker de ge- 
legenheid een programma uit te voeren zoals aangegeven door, bijvoorbeeld, de 
besturingskaarten van het gebruikersprogramma. Een interessante vraag in dit ver- 
band is: waaraan moet de besturing worden teruggegeven wanneer het geladen 
programma klaar is met zijn uitvoering? Deze vraag heeft te maken met het pro- 
bleem of het bestaande programma verloren gaat, of dat het wordt bewaard, of dat 
het tegelijk met het nieuwe programma mag doorgaan met zijn uitvoering. 

Als bij de beëindiging van het nieuwe programma de besturing aan het be- 
staande programma wordt teruggegeven, moeten we het geheugenbeeld van het be- 
staande programma bewaren en hebben we in feite een mechanisme gecreëerd voor 
het oproepen van een programma door een ander programma. Als beide program- 
ma’s gelijktijdig verder gaan, hebben we een nieuwe job of nieuw proces gecreëerd, 
waarvoor dan multiprogrammering nodig is. Dikwijls bestaat er een systeemaan- 
roep speciaal voor dit doel: creëer proces of dien job in. 
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Als we een nieuwe job of nieuw proces creëren, of wellicht zelfs een groep 
jobs of processen, moeten we de uitvoering daarvan wel kunnen besturen. Deze 
besturing vereist dat we in staat zijn de gegevenskenmerken van een job of proces 
te bepalen en opnieuw toe te kennen, zoals de prioriteit, de maximaal toegestane 
uitvoeringstijd, enzovoort (haal proces-gegevenskenmerken op en stel proces-ge- 
gevenskenmerken in). Ook kan het zijn dat we een door ons gecreëerd proces (of 
job) willen tenietdoen (doe proces teniet) als we vinden dat het proces niet correct 
of niet langer nodig is. 

Na het creëren van nieuwe jobs of processen kan het nodig zijn dat we wach- 
ten tot de uitvoering daarvan gereed is. We willen misschien een bepaalde tijd 
wachten (wacht tijd), maar het is waarschijnlijker dat we op een bepaalde gebeur- 
tenis willen wachten (wacht gebeurtenis). De jobs of processen moeten dan het sein 
geven dat die gebeurtenis heeft plaats gevonden (sein gebeurtenis). Systeemaan- 
roepen van dit type, betrekking hebbend op de coördinatie van parallelle proces- 
sen, worden uitvoeriger besproken in hoofdstuk 9. 

Een andere groep systeemaanroepen is bedoeld als hulp bij het foutvrij ma- 
ken van een programma. Vele systemen hebben systeemaanroepen voor het maken 
van een geheugendump. Deze voorziening is nuttig voor het opsporen van fouten 
in een programma dat geschreven is in de assembleertaal of in machinetaal, vooral 
in een systeem voor groepsgewijze verwerking. Een programmatrace (detailver- 
slag) drukt iedere instructie af die wordt uitgevoerd, en is op minder systemen be- 
schikbaar. 

Door veel systemen wordt een tijdprofiel van een programma geleverd. Dit 
geeft aan hoeveel tijd het programma met de uitvoering bezig is op een bepaalde 
geheugenpositie of groep van posities. Een tijdprofiel vereist óf een trace-faciliteit 
óf regelmatige onderbrekingen met behulp van een tijdregister. Bij iedere onder- 
breking door het tijdregister wordt de waarde van de programmateller vastgelegd. 
Als de onderbrekingen voldoende frequent plaatsvinden, kan een statistisch plaat- 
je worden verkregen van de tijd doorgebracht in de onderdelen van het program- 
ma. 


Bestandsbewerkingen 
Het bestandssysteem wordt uitvoeriger besproken in hoofdstuk 3. We kunnen 
echter verscheidene algemeen gebruikelijke systeemaanroepen definiëren die te 
maken hebben met het werken met bestanden. Hun exacte betekenis zal duidelij- 
ker worden bij het lezen van hoofdstuk 3. 

We moeten eerst in staat zijn bestanden aan te maken en weer op te heffen. 
Een dergelijke systeemaanroep vereist de naam van het bestand en wellicht enige 
van zijn gegevenskenmerken. Zodra het bestand is gemaakt moeten we dit openen 
om het te gebruiken. We kunnen ook lezen, schrijven en opnieuw positioneren 
(bijvoorbeeld terugspoelen of naar het einde van het bestand springen). Tenslotte 
moeten we het bestand sluiten om aan te geven dat we het niet langer gebruiken. 

Hetzelfde stel bewerkingen kunnen we nodig hebben voor adresboeken 
(Engels: directories) als we een adresboekstructuur in het bestandssysteem heb- 
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ben. Bovendien moeten we, hetzij voor bestanden hetzij voor adresboeken, de 
waarden van diverse gegevenskenmerken kunnen bepalen en mogelijk opnieuw 
toekennen. Onder de gegevenskenmerken van een bestand vallen de naam van 
het bestand, een bestandssoort, beveiligingscodes, informatie voor doorbere- 
kening, enzovoort. Twee systeemaanroepen, haal bestandsgegevenskenmerk op 
en stel bestandgegevenskenmerk in zijn voor deze functie nodig. Paragraaf 3.2.2 
bespreekt veel gebruikte bestandsgegevenskenmerken. 


Randapparatuurbeheer 
Bestanden kunnen worden gezien als abstracte of virtuele randapparaten. Zo zijn 
vele van de systeemaanroepen voor bestanden ook nodig voor randapparaten. 
Indien er echter meerdere gebruikers van het systeem zijn, moeten we eerst 
het randapparaat aanvragen om er zeker van te zijn dat alleen wij de beschikking 
erover hebben. Nadat we klaar zijn met het randapparaat moeten we het vrijge- 
ven. Dit zijn soortgelijke functies als de open/sluit-functies voor bestanden. 
Zodra het randapparaat eenmaal is aangevraagd (en aan ons toegewezen), 
kunnen we van het apparaat lezen, ernaar schrijven, en het (eventueel) opnieuw 
positioneren, net zoals met bestanden. In feite is de overeenkomst tussen randap- 
paraten en bestanden zo groot dat veel besturingssystemen de twee samenvoegen 
tot één gecombineerde bestands-/randapparaatstructuur. In dit geval krijgen 
randapparaten een speciaal soort bestandsnaam. 


Het bijhouden van informatie 

Veel systeemaanroepen danken hun bestaan aan het doel informatie over te bren- 
gen tussen het gebruikersprogramma en het besturingssysteem. De meeste syste- 
men hebben bijvoorbeeld een systeemaanroep om de tijd en de datum van dat 
moment op te vragen. Andere systeemaanroepen kunnen informatie teruggeven 
over het systeem, zoals het aantal gebruikers op dat moment, het versienummer 
van het besturingssysteem, de hoeveelheid vrij geheugen of vrije ruimte op schijf, 
enzovoort. 

Bovendien houdt het besturingssysteem informatie bij over alle jobs en 
processen, en zijn er systeemaanroepen om tot deze informatie toegang te krijgen. 
In het algemeen zijn er ook systeemaanroepen om deze informatie opnieuw in te 
stellen (haal procesgegevenskenmerken op en stel procesgegevenskenmerken in). 
In paragraaf 4.2.1 bespreken we welke informatie gewoonlijk wordt bij gehouden. 

Figuur 2.1 geeft een overzicht van de verschillende soorten systeemaanroe- 
pen die gewoonlijk door een besturingssysteem worden geleverd. 


2.2.2 Implementatie van systeemaanroepen 
Systeemaanroepen vinden op verschillende manieren plaats, afhankelijk van de 


gebruikte computer. Op de IBM 360/370 bijvoorbeeld is er een speciale instructie 
voor systeemaanroepen (supervisor call, SVC) die rechtstreeks in de ’val’ van 
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@ Procesbesturing. 
O Beëindig, Beëindig voortijdig 
O Laad, Voer uit 
O Creëer proces, Doe proces teniet 
O Haal procesgegevenskenmerken op, Stel procesgegevenskenmerken in 
O Wacht op tijd 
O Wacht op gebeurtenis, Sein gebeurtenis 


@ Bestandsbewerking. 
O Maak bestand, Hef bestand op 
O Open, Sluit 
O Lees, Schrijf, Positioneer opnieuw 
O Haal bestandsgegevenskenmerken op, Stel bestandsgegevens- 


kenmerken in 


@ Randapparatuurbewerkingen. 
O Vraag randapparaat aan, Geef randapparaat vrij 
O Lees, Schrijf, Positioneer opnieuw 
O Haal apparaatgegevenskenmerken op, Stel apparaatgegevens- 


kenmerken in 


@ Het onderhouden van informatie. 
O Haal tijd/datum op, Stel tijd/datum in 
O Haal systeemgegevens op, Stel systeemgegevens in 
O Haal proces-/bestands-/randapparaatgegevenskenmerken op, 


Stel proces-/bestands-/randapparaatgegevenskenmerken in. 


Figuur 2.1 
Soorten systeemaanroepen 
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het besturingssysteem loopt. De minst significante 8 bits van de systeemaanroep 
specificeren een getal dat het soort aanroep identificeert. 

CP/M draait op de Intel 8080, die geen speciale systeemaanroep-instructie 
heeft. Een aanroep vindt plaats door het functienummer in register C te plaatsen 
en rechtstreeks naar geheugenpositie 5 te springen. 

Dikwijls is meer informatie vereist dan alleen het identificeren van de ge- 
wenste systeemaanroep. De exacte soort en hoeveelheid informatie varieert met 
het desbetreffende besturingssysteem en de aanroep. Bijvoorbeeld, om een kaart- 
beeld te lezen kan het nodig zijn dat we specificeren welk bestand of randappa- 
raat gebruikt moet worden, evenals het adres en de lengte van de geheugenbuffer 
waarin dit ingelezen moet worden. Natuurlijk kan het apparaat of bestand impli- 
ciet in de aanroep gegeven zijn en hoeven we wellicht, als de kaartbeelden altijd 
uit 80 tekens bestaan, de lengte niet te specificeren. 

Er worden twee algemene methoden gebruikt om parameters aan het bestu- 
ringssysteem door te geven. De eenvoudigste manier is de parameters door te 
geven in registers. In sommige gevallen echter kunnen er meer parameters dan 
registers zijn. In deze gevallen worden deze parameters gewoonlijk opgeborgen 
in een blok of tabel in het geheugen en wordt het adres van het blok als een 
parameter in een register doorgegeven (zie figuur 2.2). Sommige besturingssys- 
temen geven de voorkeur aan deze uniforme koppeling, zelfs wanneer er in de 
meeste gevallen genoeg registers zijn om alle parameters te kunnen bevatten. 

Systeemaanroepen zijn alleen algemeen beschikbaar in de assembleertaal. 
Sommige systemen laten wel toe dat systeemaanroepen rechtstreeks plaatsvinden 


Register 


X: parameters 
voor de 
aanroep 


Gebruik parameters Code 


Laad adres X uit tabel X voor 
SVC 13 SVC 13 


Gebruikers- 
programma 


Besturingssysteem 


Figuur 2.2 
Het doorgeven van parameters in tabelvorm 
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vanuit een programma in een hogere programmeertaal, in welk geval de aanroe- 
pen gewoonlijk lijken op van tevoren gedefinieerde functie- of subroutineaanroe- 
pen. Deze kunnen dan tijdens de uitvoering een aanroep genereren van een spe- 
ciale routine die de systeemaanroep doet, of de systeemaanroep kan rechtstreeks 
in de code (in-line) worden gegenereerd. 

Er zijn verschillende talen gedefinieerd, zoals C [Kernighan en Ritchie 
1978], Bliss [Wulf et al. 1971], en PL/360 [Wirth 1968], om de assembleertaal 
voor systeemprogrammering te vervangen. Deze talen geven de mogelijkheid 
rechtstreekse systeemaanroepen te doen. Sommige Pascal-systemen hebben ook 
een faciliteit om het besturingssysteem rechtstreeks vanuit een Pascal-programma 
aan te roepen. De meeste FORTRAN-systemen hebben soortgelijke mogelijkhe- 
den, vaak door middel van een stel bibliotheekroutines. 

Laten we, als voorbeeld van hoe systeemaanroepen worden gebruikt, eens 
denken aan het schrijven van een eenvoudig programma om gegevens uit een 
bestand te lezen en deze te kopiéren naar een ander bestand. Wat het programma 
het eerst nodig heeft zijn de namen van de twee bestanden, het invoerbestand en 
het uitvoerbestand. Deze kunnen op twee manieren worden gespecificeerd. Eén 
manier is dat het programma de twee bestandsnamen opvraagt bij de gebruiker. 
In een interactief systeem zal dit een reeks systeemaanroepen vereisen om eerst 
een verzoek om informatie op de terminal te schrijven en dan van de terminal de 
tekens te lezen die de twee bestanden definiëren. Een andere manier, in het bij- 
zonder gebruikt voor systemen voor groepsgewijze verwerking, is de namen van 
de bestanden te specificeren met gebruikmaking van besturingskaarten. In dit 
geval moet er een mechanisme zijn om deze parameters van de besturingskaarten 
door te geven naar het in uitvoering zijnde programma. 

Zijn de twee namen eenmaal verkregen. dan moet het programma het in- 
voerbestand openen en het uitvoerbestand maken. Elk van deze bewerkingen 
vereist weer een systeemaanroep. Bij elke bewerking kunnen ook fouten optre- 
den. Wanneer het programma het invoerbestand tracht te openen kan het gebeu- 
ren dat er geen bestand met die naam is, of dat het bestand beveiligd is tegen 
toegang. In deze gevallen moet het programma een boodschap op het bedienings- 
paneel afdrukken (weer een reeks systeemaanroepen) en dan abnormaal eindigen 
(nog een systeemaanroep). Bestaat het invoerbestand, dan moeten we een nieuw 
uitvoerbestand maken. Het kan zijn dat we ontdekken dat er al een uitvoerbe- 
stand met dezelfde naam bestaat. Deze situatie kan er oorzaak van zijn dat het 
programma voortijdig eindigt (weer een systeemaanroep), of we kunnen het be- 
staande uitvoerbestand opheffen (weer een systeemaanroep) en een nieuw aan- 
maken (nog een systeemaanroep). Een andere optie, in een interactief systeem, 
is de gebruiker te vragen (een reeks systeemaanroepen om het verzoek om infor- 
matie te sturen naar en het antwoord te lezen van de terminal) of het bestaande 
bestand opgeheven moet worden of dat voortijdige beéindiging moet plaats vin- 
den. 

Nu beide bestanden opgezet zijn, gaan we een lus binnen die van het invoer- 
bestand leest (een systeemaanroep) en naar het uitvoerbestand schrijft (ook een 
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systeemaanroep). Iedere lees- en schrijfbewerking moet statusinformatie terug- 
geven betreffende verschillende mogelijke foutcondities. Bij invoer kan het pro- 
gramma de situatie tegenkomen dat het eind van het bestand bereikt is, of dat 
er een apparatuurfout bij het lezen is opgetreden (zoals een pariteitsfout). De 
schrijfbewerking kan op diverse fouten stuiten, afhankelijk van het uitvoerappa- 
raat (geen schijfruimte meer, het fysieke einde van de band, het papier in de 
printer is op, enzovoort). : 

Tenslotte kan het programma, nadat het gehele bestand is gekopieerd, beide 
bestanden sluiten (weer een systeemaanroep), een boodschap schrijven op het 
bedieningspaneel (nog meer systeemaanroepen) en uiteindelijk normaal eindigen 
(de laatste systeemaanroep). Zoals we kunnen zien, maken programma’s intensief 
gebruik van het besturingssysteem. Alle interacties tussen het programma en zijn 
omgeving moeten gebeuren als resultaat van verzoeken aan het besturingssysteem 
vanuit het programma. | 

De meeste gebruikers zien dit soort details evenwel nooit. Het ondersteu- 
nende systeem ten tijde van de uitvoering beschikt over een veel eenvoudiger 
koppeling. Bijvoorbeeld, een schrijf-opdracht in Pascal of FORTRAN wordt 
hoogstwaarschijnlijk vertaald in een aanroep van een uitvoeringshulproutine die 
de nodige systeemaanroepen doet, nagaat of er fouten zijn opgetreden, en tenslot- 
te teruggaat naar het gebruikersprogramma. Aldus worden de meeste details van 
de koppeling met het besturingssysteem aan het oog van de gebruiker-program- 
meur onttrokken door het vertaalprogramma en het bijbehorende pakket ter on- 
dersteuning tijdens de uitvoering. 


2.2.3 Systeemprogramma’s 


Een ander aspect van een modern systeem is zijn verzameling systeemprogram- 
ma’s. Hoewel we een programma zouden kunnen schrijven om het ene bestand 
naar een ander te kopiëren, is het onwaarschijnlijk dat we dat zouden willen 
doen. Naast de eigenlijke monitorcode van het besturingssysteem voorzien de 
meeste systemen ons van een grote collectie systeemprogramma’s voor het oplos- 
sen van vaak voorkomende problemen en voor het scheppen van een gemakkelij- 
kere werkomgeving voor het ontwikkelen en uitvoeren van programma’s. 
Systeemprogramma’s kunnen in diverse categorieën worden onderverdeeld: 


© Bestandsbewerking. Deze programma’s zorgen voor het aanmaken, opheffen, 
kopiëren, herbenoemen, afdrukken, dumpen, uitlijsten, en in het algemeen het 
bewerken van bestanden en adresboeken. 

@ Statusinformatie. Sommige programma’s vragen het besturingssysteem ge- 
woon naar de datum, tijd, hoeveelheid beschikbare geheugenruimte of ruimte 
op schijf, aantal gebruikers, of soortgelijke statusinformatie. Die informatie 
wordt dan in een bepaald formaat gebracht en op de terminal of ander uitvoer- 
apparaat of -bestand afgedrukt. 
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@ Bestandswijziging. Verscheidene tekstopmaakprogramma’s kunnen beschik- 
baar zijn om de inhoud van bestanden die op schijf of band opgeslagen zijn 
aan te maken en te wijzigen. 

@ Programmeertaalondersteuning. Compileerprogramma’s, assembleerprogram- 
ma’s en vertolkers voor algemene programmeertalen (zoals FORTRAN, CO- 
BOL, Pascal, BASIC, enzovoort) worden dikwijls met het besturingssysteem 
meegeleverd. Sinds kort krijgen veel van deze programma’s een eigen prijs- 
kaartje en worden ze afzonderlijk geleverd. 

@ Laden en uitvoeren van programma’s. Nadat een programma geassembleerd 
of gecompileerd is, moet het in het geheugen worden geladen om te worden 
uitgevoerd. Het systeem kan absolute laadprogramma’s, verplaatsbare laad- 
programma’s, montageprogramma’s en overlappende laadprogramma’s heb- 
ben. Systemen voor het foutvrij maken van programma’s in hetzij de assem- 
bleertaal hetzij machinetaal zijn ook nodig. 

@ Toepassingsprogramma’s. Daarnaast komen de meeste besturingssystemen 
met programma’s die nuttig zijn voor het oplossen van een aantal zeer alge- 
mene problemen, zoals compiler-compilers, tekstopmaakprogramma’s, pak- 
ketten voor plotters, database-systemen, pakketten voor statistische analyse, 
enzovoort. 


Het belangrijkste systeemprogramma voor een besturingssysteem is wel- 
licht de commandovertolker. De commandovertolker is het programma dat draait 
wanneer op cen systeem met tijddeling een job aan zijn uitvoering begint of een 
gebruiker zich aanmeldt. 

Veel commando’s worden aan het besturingssysteem via besturingskaarten 
gegeven. (Besturingskaarten zijn commando’s die in een omgeving voor groeps- 
gewijze verwerking worden gegeven; commando’s in een interactieve omgeving 
zijn een soort besturingskaarten.) Wanneer in een systeem voor groepsgewijze 
verwerking een nieuwe job wordt gestart, of wanneer in een systeem met tijd- 
deling een gebruiker zich aanmeldt, wordt automatisch een programma uitge- 
voerd dat besturingskaarten leest en interpreteert. Dit programma staat bekend 
onder verschillende namen: (1) de besturingskaartvertolker, (2) de commando- 
regelvertolker, (3) het verwerkingsprogramma voor bedieningspaneelcomman- 
do’s (console command processor, in CP/M), (4) de schil (shell, in Unix), enzo- 
voort. De functie ervan is heel eenvoudig: haal het volgende commando (de vol- 
gende besturingskaart) op en voer deze uit. 

Veel commando’s die op dit niveau gegeven worden zijn voor het werken 
met bestanden: maak, hef op, lijst, kopieer, voer uit, enzovoort. Deze comman- 
do’s zijn op twee algemene manieren geimplementeerd. In het ene geval bevat de 
commandovertolker zelf de code voor het uitvoeren van het commando. Bijvoor- 
beeld, een commando om een bestand op te heffen kan de commandovertolker 
doen springen naar een deel van zijn code dat de parameters opzet en de juiste 
systeemaanroep doet. In dit geval wordt de grootte van de commandovertolker 
bepaald door het aantal commando’s dat kan worden gegeven, aangezien elk 
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commando zijn eigen code voor de uitvoering ervan vereist. 

Een tweede aanpak zorgt ervoor dat de commando's door middel van spe- 
ciale systeemprogramma’s worden uitgevoerd. In dit geval begrijpt’ de comman- 
dovertolker het commando in geen enkel opzicht; hij gebruikt het commando 
enkel en alleen om een bestand te identificeren dat in het geheugen moet worden 
geladen en uitgevoerd. Dus een commando: 


delete G (hef G op) 


zoekt dan een bestand op met de naam delete, laadt dit in het geheugen en geeft 
het een parameter door: G. De functie verbonden met het delete-commando 
wordt dan volledig bepaald door de code in het bestand delete. Op deze manier 
kunnen nieuwe commando’s gemakkelijk aan het systeem worden toegevoegd 
door nieuwe bestanden met de juiste naam te maken. Het commandovertolkings- 
programma, dat nu heel klein kan zijn, hoeft voor het toevoegen van nieuwe 
commando’s niet veranderd te worden. 

Er zijn problemen met deze benadering voor het ontwerpen van een com- 
mandovertolker. Ten eerste moet u erop letten dat het besturingssysteem een 
mechanisme moet verschaffen voor het doorgeven van parameters van de com- 
mandovertolker naar het systeemprogramma; de code om een commando uit te 
voeren is namelijk een afzonderlijk systeemprogramma. Dit kan dikwijls een heel 
onhandige taak zijn, omdat het wel eens kan voorkomen dat de commandovertol- 
ker en het systeemprogramma niet beide tegelijkertijd in het geheugen zijn. 

Het tweede probleem is dat de interpretatie van de parameters volledig 
wordt overgelaten aan de programmeur van het systeemprogramma. Dit zou kun- 
nen betekenen dat parameters niet consistent worden gebruikt door programma's 
die ervoor de gebruiker eender uitzien, maar die op verschillende tijden door 
verschillende programmeurs werden geschreven. 

Hoe het besturingssysteem op de meeste gebruikers overkomt wordt dan 
bepaald door de systeemprogramma’s, en niet door de eigenlijke systeemaanroe- 
pen. Dientengevolge kan dit beeld een heel eind bezijden de werkelijkheid zijn. 
De problemen bij het ontwerpen van een bruikbare en vriendelijke koppeling 
met de gebruiker zijn legio, maar die zijn geen directe functies van het besturings- 
systeem. In dit boek zullen we ons concentreren op de fundamentele problemen 
die samenhangen met een doeltreffende dienstverlening aan de gebruikerspro- 
gramma’s. Vanuit het gezichtspunt van het besturingssysteem maken we geen 
onderscheid tussen gebruikerprogramma’s en systeemprogramma’s. 


2.3 Functies gezien vanuit het besturingssysteem 
Hoe de gebruiker het besturingssysteem ziet wordt hoofdzakelijk bepaald door 


de systeemprogramma’s, in het bijzonder de commandovertolker. De program- 
meur van het besturingssysteem ziet het daarentegen heel anders. Waar de gebrui- 
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ker die faciliteiten ziet die door het besturingssysteem worden verleend, ziet de 
systeemprogrammeur alleen de fysieke hulpmiddelen en randapparatuur, en 
moet hij deze omvormen tot de logische faciliteiten die verleend moeten worden 
aan de gebruiker. Laten we eens zien hoe de structuur van het besturingssysteem 
in elkaar zit. 

Besturingssystemen zijn gebeurtenisgestuurde programma’s. Als er geen jobs 
zijn die uitgevoerd moeten worden, geen randapparaten die bediend moeten wor- 
den, en geen gebruikers die respons verwachten, zal een besturingssysteem rustig 
zitten wachten tot er iets gebeurt. Gebeurtenissen worden bijna altijd gesig- 
naleerd doordat er een onderbreking of ’val’ plaatsvindt. Dus een besturingssys- 
teem is onderbrekinggestuurd. 

Het onderbrekinggestuurde karakter van een besturingssysteem bepaalt 
zijn algemene structuur. Wanneer er een onderbreking (of ’val’) optreedt, draagt 
de apparatuur de besturing over aan het besturingssysteem. Eerst stelt het bestu- 
ringssysteem de status van de CVE veilig door de registers en de programmateller 
op te bergen. Dan bepaalt het welk soort onderbreking heeft plaatsgevonden. Dit 
bepalen kan navraag (Engels: polling) vereisen, of het kan het natuurlijke gevolg 
zijn van het feit dat het onderbrekingssysteem met een vector is uitgerust. Er 
kunnen diverse verschillende soorten onderbrekingen optreden: 


@ Een systeemaanroep. 
@ Een onderbreking door een randapparaat. 
@ Een programmafout. 


Voor elk soort onderbreking bepalen afzonderlijke codesegmenten in het bestu- 
ringssysteem welke actie moet worden ondernomen. 


2.3.1 Systeemaanroepen 


Aanroepen van het besturingssysteem worden onderverdeeld aan de hand van 
het soort aanroep. Elke aanroep heeft zijn eigen codesegment om de gewenste 
actie gestalte te geven. In het algemeen zullen we tegenkomen: 


@ Normale beéindiging. Als een systeemaanroep wordt gedaan om het momen- 
teel lopende programma normaal te beéindigen, moet het besturingssysteem 
de besturing overdragen aan de commandovertolker. De commandovertolker 
leest dan de volgende besturingskaart of het volgende commando om de vol- 
gende job-stap te bepalen. 

@ Abnormale beéindiging. Een programma dat een fout ontdekt in de verwerking 
van gegevens en tot abnormale beéindiging besluit, kan een geheugendump en 
een foutmelding vereisen. Vervolgens wordt de commandovertolker aangeroe- 
pen. In een interactief systeem gaat de commandovertolker gewoon verder met 
het volgende commando; er wordt van uitgegaan dat de gebruiker een geschikt 
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commando zal geven om op de fout te reageren. In een systeem voor groeps- 
gewijze verwerking beëindigt de commandovertolker gewoonlijk de gehele job 
en gaat verder met de volgende job. Sommige systemen bieden de mogelijkheid 
dat een besturingskaart speciale foutenherstelacties aangeeft voor het geval 
dat er een fout optreedt. 

@ Statusverzoeken. Eén groep van systeemaanroepen vraagt alleen maar infor- 
matie op bij het besturingssysteem. Zulke verzoeken houden onder meer in het 
vragen om de datum of tijd, de gegevenskenmerken van bestanden of jobs, of 
de status van diverse systeemfaciliteiten (zoals: hoeveel geheugen is er beschik- 
baar?). De gewenste informatie wordt berekend en verschaft, en de besturing 
wordt teruggegeven aan het lopende programma. 

@ Verzoeken om systeemfaciliteiten. Een programma kan tijdens de uitvoering 
voor zijn verdere voortgang extra systeemfaciliteiten nodig hebben. Dat kun- 
nen zijn: meer geheugen, magneetbandeenheden, toegang tot bestanden, enzo- 
voort. Als de systeemfaciliteiten beschikbaar zijn, kan aan het verzoek worden 
voldaan en kan de besturing worden teruggegeven aan het gebruikersprogram- 
ma, anders zal het programma moeten wachten tot er voldoende systeemfaci- 
liteiten beschikbaar zijn. 

@ Verzoeken om I/O. De meeste verzoeken zullen echter betrekking hebben op 
in- en uitvoer. Het merendeel van de programma’s zal tijdens hun uitvoering 
vaak lezen of schrijven van en naar randapparaten of bestanden. 


2.3.2 Onderbrekingen door de randapparatuur 


Een belangrijke groep gebeurtenissen die een besturingssysteem moet behandelen 
wordt gevormd door onderbrekingen door de randapparatuur. Een randapparaat 
zal een onderbreking veroorzaken wanneer het klaar is met het uitvoeren van 
een verzoek om I/O. Deze situatie treedt in het algemeen op als gevolg van een 
systeemaanroep om I/O door de gebruiker. Wanneer de I/O eenmaal gestart is, 
kan op twee manieren actie worden ondernomen. In het eenvoudigste geval star- 
ten we de gewenste I/O en wachten we tot deze gereed is alvorens de besturing 
terug te geven aan het gebruikersprogramma. De andere mogelijkheid is dat we 
de besturing aan het gebruikersprogramma teruggeven zonder op het gereed- 
komen van de I/O te wachten. 

Het wachten op het gereedkomen van I/O kan op twee manieren gebeuren. 
Sommige computers, zoals de IBM 370 en de PDP-11, hebben een speciale wacht- 
instructie die de CVE stilzet tot de volgende onderbreking optreedt. Machines 
die niet zo’n instructie hebben kunnen in een wacht-lus gehouden worden (waarin 
jmp de ’sprong’-instructie is): 


Lus: jmp Lus 


In dit heel kleine lusje blijft de CVE rondgaan tot er een onderbreking plaats- 
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vindt, waarbij de besturing wordt overgedragen aan een ander deel van het bestu- 
ringssysteem. De wacht-instructie is waarschijnlijk beter, omdat een wachtlus 
voortdurend een instructie uit het geheugen moet ophalen, waardoor een aanzien- 
lijke wedijver om toegang tot het geheugen wordt veroorzaakt. 

Eén voordeel van het wachten op het gereedkomen van I/O is dat er op 
elk moment ten hoogste één verzoek om I/O uitstaat. Dus wanneer er een 1/O- 
onderbreking plaatsvindt, weet het besturingssysteem precies welk randapparaat 
de onderbreking veroorzaakt. Anderzijds levert deze manier een aanzienlijke be- 
perking op van de hoeveelheid 1/O die tegelijkertijd kan plaatsvinden. 

Een andere manier is de I/O te starten en onmiddellijk de besturing aan 
het gebruikersprogramma terug te geven. Er is dan een nieuwe systeemaanroep 
nodig om de gebruiker gelegenheid te geven om op het gereedkomen van de 
I/O te wachten. Daarom is nog steeds de code voor het wachten vereist die we 
eerst ook nodig hadden. Ook moeten we kunnen bijhouden welke 1/ O-aanvragen 
er gelijktijdig worden uitgevoerd. Hiertoe maakt het besturingssysteem gebruik 
van een tabel die voor elk randapparaat een ingang bevat: de randapparaat-status- 
tabel (zie figuur 2.3). Iedere ingang van de tabel geeft aan: het type randapparaat, 
zijn adres en zijn status (buiten bedrijf, zonder werk, of bezig). Als het randappa- 
raat bezig is met een verzoek, zijn het soort verzoek en andere parameters opge- 
slagen in de tabelingang voor dat apparaat. Aangezien het mogelijk is dat een 
programma verschillende verzoeken voor hetzelfde apparaat doet, kunnen we een 
lijst of keten van wachtende verzoeken hebben. Aldus kan een besturingssysteem 
naast de randapparaat-statustabel ook een verzoeklijst hebben voor elk apparaat. 

Een randapparaat onderbreekt de CVE wanneer het bediening nodig heeft. 


Verzoek voor 
regeldrukker 


adres: 38546 


Verzoek voor 
schijfeenheid 3 


Verzoek voor 
schijfeenheid 3 


bestand: xxx bestand: yyy 
bewerking: lees bewerking: schrijf 
adres: 43046 adres: 03458 


Figuur 2.3 
Randapparaat-statustabel 
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Wanneer een onderbreking optreedt bepalen we eerst welk randapparaat de on- 
derbreking veroorzaakte. Met het apparaatnummer als index gaan we de rand- 
apparaat-statustabel in om de status van dat apparaat vast te stellen, en wijzigen 
we de tabelingang zodanig dat het optreden van de onderbreking daarin wordt 
weergegeven. Voor de meeste randapparaten betekent een onderbreking dat aan 
het verzoek om I/O voldaan is. Als er nog meer verzoeken wachten voor dit 
apparaat, beginnen we aan de verwerking van het volgende verzoek. 

Tenslotte wordt, na afhandeling van de I/O-onderbreking, de besturing te- 
ruggegeven. Als een programma wachtte op afhandeling van het verzoek (zoals 
vastgelegd in de randapparaat-statustabel), geven we het nu de besturing terug. 
Anders gaan we terug naar datgene wat we aan het doen waren voor de onder- 
breking. Dit kan zijn de uitvoering van het gebruikersprogramma (het program- 
ma startte een I/O-bewerking en die bewerking is nu beëindigd, maar het pro- 
gramma heeft nog niet gewacht op het gereedkomen daarvan), of de wachtlus 
(het programma heeft twee of meer I/O-bewerkingen gestart en wacht nu op 
het gereedkomen van één ervan, maar deze onderbreking kwam van een van de 
andere). 

Sommige randapparaten kunnen iets afwijken van deze opzet. Veel interac- 
tieve systemen geven gebruikers de gelegenheid om op hun terminal vooruit te 
typen. In dit geval kunnen onderbrekingen optreden om het sein te geven dat 
er tekens van de terminal zijn aangekomen, terwijl het randapparaat-statusblok 
aangeeft dat geen enkel programma om invoer van dit apparaat heeft verzocht. 
Als vooruit typen is toegestaan, moet er een buffer zijn om de vooruit getypte 
tekens op te slaan tot een of ander programma ze wil hebben. In het algemeen 
kunnen we een buffer nodig hebben voor iedere invoerterminal. 

Een andere situatie treedt op wanneer er een onderbreking wordt gegene- 
reerd door het tijdregister. Dit soort onderbreking geeft te kennen dat een bepaal- 
de tijd verstreken is, en geeft het besturingssysteem de gelegenheid de tijd te 
berekenen gerekend vanaf een zekere aanvangstijd. Als we iedere 1 seconde zo’n 
onderbreking hebben, en we 1427 onderbrekingen hebben gehad sinds we hoor- 
den dat het 1 uur ’s middags was, kunnen we uitrekenen dat het nu 1u23m47s in 
de namiddag moet zijn. De meeste computers bepalen op deze manier de tijd. 

Een ander gebruik van onderbrekingen door het tijdregister is dat we zo 
kunnen voorkomen dat een gebruikersprogramma te lang draait. Een eenvoudige 
techniek bestaat hierin dat we een teller een aanvangswaarde geven gelijk aan 
de hoeveelheid tijd die een programma mag draaien. Een programma met een 
tijdslimiet van zeven minuten bijvoorbeeld zou in de teller de aanvangswaarde 
420 hebben. Iedere seconde komt er een onderbreking door het tijdregister en 
wordt de waarde in de teller met één verminderd. Zolang de teller een positieve 
waarde heeft, wordt de besturing aan het gebruikersprogramma teruggegeven. 
Wordt de teller negatief, dan beëindigen we het programma. 
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2.3.3 Programmafouten 


Een derde soort onderbrekingen heeft te maken met programmafouten. Bepaalde 
soorten programmafouten (zoals een illegale instructie, een poging een bevoor- 
rechte instructie uit te voeren, of een illegale geheugenverwijzing) veroorzaken 
een ‘val’ van de apparatuur. De val draagt, net als een onderbreking, de besturing 
via de onderbrekingsvector over aan het besturingssysteem. 

Wanneer er een programmafout optreedt, moet het besturingssysteem het 
programma abnormaal beëindigen. Deze situatie wordt door dezelfde code be- 
handeld als een abnormale beëindiging op verzoek van de gebruiker. Een geschik- 
te foutmelding wordt gegeven en het programmageheugen wordt gedumpt. In een 
systeem voor groepsgewijze verwerking kan de geheugendump worden afgedrukt, 
zodat de gebruiker de gelegenheid heeft de oorzaak van de fout op te sporen 
door het inspecteren van de afgedrukte dump. In een interactief systeem kan de 
geheugendump naar een bestand worden weggeschreven. De gebruiker kan dit 
dan afdrukken of gekoppeld (on-line) inspecteren, en wellicht het programma 
corrigeren en opnieuw starten. 


2.3.4 Algemeen stroomschema 
Figuur 2.4 laat het algemene stroomschema van een besturingsysteem zien. Het 


Onderbreking 


Stel registers veilig 


Welk soort? 
Einde Fout Niet-l/O-verzoek |/O-verzoek IZO klaar 
Dum 
Volgende Job p ek Start Merk 


of Commando bewerking Klaar’ 


Wacht 


Geef besturing terug 


aan de gebruiker 
Figuur 2.4 


Algemeen stroomschema van een besturingssysteem 
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is duidelijk dat geen enkel werkelijk bestaand besturingssysteem exact met deze 
structuur overeenkomt. De meeste besturingssystemen zullen er evenwel een ze- 
kere gelijkenis mee vertonen. We kunnen nu bepaalde veel voorkomende gedeel- 
ten van besturingssystemen identificeren. 

Een besturingssysteem heeft stuurprogramma’s voor de randapparatuur, 
een programma voor het afhandelen van onderbrekingen, een groep routines voor 
systeemaanroepen, en een commando- of besturingskaartvertolker. Een ander 
hoofdbestanddeel van een besturingssysteem is het bestandssysteem, dat we in 
hoofdstuk 3 bespreken. 

Deze elementen zijn voldoende om een besturingssysteem te definiëren. Het 
CP/M-besturingssysteem, dat uitermate populair is in microcomputersystemen, 
heeft in essentie deze structuur. Het bestaat uit stuurprogramma’s voor de rand- 
apparatuur (BIOS), een bestandssysteem (BDOS), en een commandovertolker 
(CCP) (zie figuur 2.5). De meeste besturingssystemen hebben nog meer functies 
en zijn dientengevolge veel complexer, zoals we zullen zien in de rest van dit 
boek. 

Let er evenwel op dat een uniprogrammeringssysteem voor één gebruiker 
veel minder complex is dan een besturingssysteem met multiprogrammering voor 
meerdere gebruikers. Wij houden ons in dit leerboek voornamelijk bezig met de 
problemen en oplossingen die men voor besturingssystemen met multiprogram- 
mering heeft gedefinieerd. 


2.4 Samenvatting 


Besturingssystemen verrichten een aantal functies. Op het laagste niveau geven 
systeemaanroepen een lopend programma de mogelijkheid rechtstreeks verzoe- 
ken tot het besturingssysteem richten. Op een hoger niveau levert de comman- 
dovertolker een mechanisme om een gebruiker een verzoek te laten doen zonder 
dat hij een programma hoeft te schrijven. Commando's kunnen van kaarten ko- 
men (in een systeem voor groepsgewijze verwerking) of rechtstreeks van de ter- 
minal (in een interactief systeem of systeem met tijddeling). Systeemprogramma’s 
leveren nog een mechanisme om aan verzoeken door de gebruiker te voldoen. 

Het soort verzoek varieert met het niveau van het verzoek. Het niveau van 
de systeemaanroep moet de basisfuncties mogelijk maken, zoals procesbesturing 
en het werken met bestanden en randapparaten. Verzoeken op hogere niveaus, 
die worden uitgevoerd door de commandovertolker of systeemprogramma’s, wor- 
den vertaald in een reeks systeemaanroepen. Systeemfuncties kunnen in diverse 
categorieën worden verdeeld: programmabesturing, verzoeken om statusinforma- 
tie, en verzoeken om I/O. Programmafouten kunnen als impliciete verzoeken om 
dienstverlening worden beschouwd. 

Wanneer eenmaal de systeemfuncties zijn gedefinieerd, kan de structuur 
van het besturingssysteem worden ontwikkeld. Er zijn diverse tabellen nodig voor 
het vastleggen van de informatie die de toestand van het computersysteem en 
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Figuur 2.5 


Structuur van het CP/M-besturingssysteem 


stuurprogramma's randapparatuur 


bestandssysteem 


bedieningspaneelcommando-vertolker 


gebruikers- of systeemprogramma 


zijn jobs bepalen. 

Besturingssystemen worden gewoonlijk door onderbrekingen gestuurd. De 
verschillende gedeelten van het besturingssysteem corresponderen met de ver- 
schillende onderbrekingen, ‘vallen’ en systeemaanroepen. 


Bibliografische verwijzingen 


Besturingssysteemfuncties worden behandeld door Shaw [1974, paragraaf 1.4] en 
Kurzban et al. [1975, hoofdstuk 3]. Een goede bespreking van onderbrekingen 
door de randapparatuur wordt gegeven door Lister [1979, paragraaf 6.3]. 

Om feitelijke besturingssysteemcode te zien, zou u kunnen kijken in Mad- 
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nick en Donovan [1974, hoofdstuk 7] (een voorbeeld van een multiprogram- 
meringssysteem voor een IBM 360), Brinch Hansen [1977] (het Solo-besturings- 
systeem voor de PDP-11 geschreven in Concurrent (parallel) Pascal), Brinch 
Hansen [1983] (het Edison systeem voor de IBM PC), of Lions [1977] (de bron- 
code van Unix versie 6 in C voor een PDP-11, plus een doorlopend commentaar). 

Unger [1975] houdt zich bezig met diverse aspecten van commandotalen. 
Bijzonder interessant is het overzicht van Gram en Hertweck [1975]. Brown 
[1978] geeft een iets recenter overzicht van ontwikkelingen op het gebied van 
commandotalen. 

Commandotalen kunnen worden gezien als programmeertalen voor specia- 
le doeleinden. Brunt en Tuffs [1976] betogen dat een commandotaal een overvloe- 
dige hoeveelheid functies moet bezitten, terwijl Frank [1976] pleit voor een be- 
perktere, eenvoudigere commandotaal. Een uitstekende praktijkstudie vormt de 
Unix-schil, zoals beschreven door Bourne [1978]. 


3 


BESTANDSSYSTEMEN 


Voor de meeste gebruikers is het bestandssysteem het aspect van een besturings- 
systeem dat het meest zichtbaar is. In bestanden worden gegevens en program- 
ma’s opgeslagen. In de praktijk geeft het besturingssysteem vorm aan het abstrac- 
te idee van een bestand door middel van het beheren van de randapparatuur 
voor de massale opslag van gegevens, zoals magneetbanden en schijven. In dit 
hoofdstuk bekijken we de verschillende manieren om een relatie te leggen tussen 
bestanden en de randapparatuur. Ook zien we hoe bestanden gewoonlijk worden 
georganiseerd met behulp van adresboeken (directories); daarom nemen we di- 
verse adresboekstructuren onder de loep. Tenslotte zien we, wanneer meerdere 
gebruikers tot bestanden toegang hebben, dat het wenselijk kan zijn erop toe te 
zien wie toegang hebben tot bestanden en hoe dit gebeurt. Dit soort toezichtsbe- 
heer staat bekend als bestandsbeveiliging. 


3.1 Het begrip ’bestand’ 


Het beheren van bestanden is een van de meest in het oog lopende functies van 
een besturingssysteem. Computers kunnen informatie opslaan in diverse fysieke 
vormen; magneetband, schijf en trommel zijn de meest gebruikte vormen. Elk 
van dit sport randapparaten heeft zijn eigen kenmerkende eigenschappen en fy- 
sieke organisatie. 

Met het oog op een gemakkelijk gebruik van het computersysteem biedt 
het besturingssysteem een uniform logisch beeld van informatie-opslag. Het be- 
sturingssysteem maakt zich los van de fysieke eigenschappen van zijn opslagap- 
paratuur en definieert een logische opslageenheid, het bestand. Het besturingssys- 
teem legt de relaties tussen bestanden en de fysieke randapparatuur. 

Wat is een bestand? Een bestand is een verzameling verwante informatie, 
als zodanig gedefinieerd door de persoon die het heeft opgezet. Gewoonlijk verte- 
genwoordigen bestanden programma’s (zowel bron- als doelprogramma’s) alsook 
gegevens. Gegegevensbestanden kunnen numeriek, alfabetisch of alfanumeriek 
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zijn. Bestanden kunnen een vrij formaat hebben, zoals bestanden bestaande uit 
tekst, of een formaat dat onderworpen is aan strikte voorschriften. In het alge- 
meen is een bestand een reeks bits, bytes, regels of records, waarvan de betekenis 
wordt bepaald door de maker en door de gebruiker. Het is een heel algemeen 
begrip. 

Een bestand heeft een naam en men verwijst naar een bestand met behulp 
van de naam. Elk bestand heeft nog bepaalde andere eigenschappen, zoals het 
soort bestand, het tijdstip waarop het werd gemaakt, de naam (of het rekening- 
nummer) van degene die het heeft gemaakt, de lengte, enzovoort. 

Men kan een bestand enigzins vergelijken met een magneetband. Aanvan- 
kelijk is deze leeg, maar er kan informatie op worden geschreven, die wordt opge- 
slagen en die later weer kan worden teruggelezen in de computer. Deze zelfde 
informatie kan diverse malen worden gelezen. Verwijzing naar een bepaalde mag- 
neetband vindt plaats door middel van de naam of het nummer van de band. 
Wat op de band staat kan worden gewijzigd en er kan informatie aan het eind 
worden toegevoegd. Een band kan worden teruggespoeld en er kan weer nieuwe 
informatie op worden geschreven, waarbij de oude informatie uitgewist wordt. 


3.1.1 Soorten bestanden 


De informatie in een bestand wordt bepaald door degene die het bestand maakt. 
Veel verschillende soorten informatie kunnen in een bestand worden opgeslagen: 
bronprogramma’s, doelprogramma’s, numerieke gegevens, tekst, salarisrecords, 
enzovoort. Een bestand heeft een zekere vastgestelde structuur die overeenstemt 
met het gebruik van het bestand. Een bestand bestaande uit tekst is een reeks 
tekens die georganiseerd zijn in de vorm van regels (en mogelijk pagina’s); een 
bestand bestaande uit bronprogramma’s is een reeks subroutines en functies, die 
elk weer verder georganiseerd zijn als declaraties gevolgd door uitvoerbare op- 
drachten; een bestand bestaande uit doelprogramma’s is een reeks woorden die 
georganiseerd zijn in de vorm van recordblokken voor het laadprogramma. 

Van belang is de vraag hoeveel van deze structuur het besturingssysteem 
moet kennen en ondersteunen. Als een besturingssysteem de structuur van een 
bestand kent, kan het op redelijke wijze allerlei bewerkingen daarop uitvoeren. 
Een veel voorkomende vergissing vindt bijvoorbeeld plaats wanneer een gebrui- 
ker de binaire doelvorm van een programma probeert af te drukken. Deze poging 
produceert normaal gesproken alleen maar rommel, maar kan worden voorko- 
men indien aan het besturingssysteem is meegedeeld dat het bestand een binair 
doelprogramma is. 

Een ander voorbeeld is ontleend aan het TOPS-20 besturingssysteem. Als 
de gebruiker een doelprogramma probeert uit te voeren waarvan het bronbestand 
is gewijzigd (met edit) sinds de tijd dat het doelbestand was geproduceerd, zal 
het bronbestand automatisch opnieuw vertaald worden. Deze functie garandeert 
dat de gebruiker altijd een bijgewerkt doelbestand draait, ook al vergeet hij op- 
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nieuw te vertalen. Anders zou de gebruiker een aanzienlijke hoeveelheid tijd kun- 
nen verspillen met het draaien van het oude doelbestand. Let erop dat het bestu- 
ringssysteem, wil deze functie mogelijk zijn, in staat moet zijn het bronbestand 
te onderscheiden van het doelbestand, de tijd te controleren waarop elk bestand 
het laatst werd gewijzigd of aangemaakt, en de taal vast te stellen van het bron- 
programma (om het juiste vertaalprogramma te gebruiken). 

Er zijn nadelen aan verbonden wanneer het besturingssysteem kennis heeft 
van de structuur van een bestand. Eén probleem is de omvang die het besturings- 
systeem daardoor krijgt. Als in het besturingssysteem veertien verschillende be- 
standsstructuren zijn gedefinieerd, moet het de code bevatten om deze structuren 
op de juiste wijze te ondersteunen. Daar komt bij dat ieder bestand gedefinieerd 
moet kunnen worden als een van de bestandssoorten die door het besturingssys- 
teem worden ondersteund. Er kunnen ernstige problemen ontstaan wanneer voor 
nieuwe toepassingsprogramma’s informatie vereist is die een andere structuur 
vertoont dan die welke door het besturingssysteem worden ondersteund. 

Stel bijvoorbeeld dat een systeem twee soorten bestanden ondersteunt: 
tekstbestanden (samengesteld uit ASCII-tekens, gescheiden door een regelterug- 
loop en regelopschuiving) en uitvoerbare binaire bestanden. Als we nu (als ge- 
bruiker) een gecodeerd bestand willen definiëren, om onze bestanden ertegen te 
beschermen dat ze door ongeautoriseerde personen worden gelezen, is het moge- 
lijk dat we geen van beide bestandssoorten geschikt vinden. Het gecodeerde be- 
stand bestaat niet uit regels ASCII-tekst maar (ogenschijnlijk) uit willekeurige 
bits. Maar het is niet uitvoerbaar, hoewel het een binair bestand lijkt te zijn. Als 
gevolg daarvan moeten we misschien het mechanisme van het besturingssysteem 
voor bestandssoorten omzeilen of misbruiken, of ons coderingsschema wijzigen 
of opgeven. 

Het andere uiterste is in het besturingssysteem geen enkele bestandssoort 
dwingend voor te schrijven (en te ondersteunen). Deze benadering heeft men 
gevolgd in, onder andere, Unix. Unix beschouwt ieder bestand als een reeks van 
uit 8 bits bestaande bytes; het besturingssysteem hecht geen interpretatie aan 
deze bits. Deze aanpak geeft maximale flexibilieit, maar minimale ondersteuning. 
leder toepassingsprogramma moet zijn eigen code bevatten om een invoerbe- 
stand te interpreteren en om te zetten in de juiste structuur. 


3.1.2 Systemen op magneetband 


De eerste bestandssystemen stonden op magneetband. Ieder bestand werd op 
een afzonderlijke magneetband gezet. Het voordeel van deze benadering is zijn 
eenvoud, maar deze aanpak is weinig efficént omdat fysieke magneetbandspoelen 
heel groot zijn (normaal gesproken zo’n 800 meter band). Uit studies is gebleken 
dat de meeste bestanden klein zijn. Figuur 3.1 laat bijvoorbeeld het aantal bestan- 
den naar grootte zien voor een bepaalde dag op een PDP-11/70 met het Unix- 
besturingssysteem. Aangezien vele bestanden heel klein zijn, zouden ze slechts 
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Figuur 3.1 
Grootte van bestanden in een bestandssysteem 


een kleine hoeveelheid band in beslag nemen. Zelfs een groot bestand van 
100.000 bytes gebruikt slechts 2% van de band. 

Een ander probleem dat hiermee verband houdt treedt op bij sommige zeer 
grote bestanden, zoals gegevens van volkstellingen, die verscheidene spoelen als 
opslagruimte nodig kunnen hebben. Om deze situatie aan te kunnen beschikken 
de meeste systemen over bestanden op meerdere spoelen (Engels: multi-reel) ofwel 
meerdere informatiedragers (Engels: multi-volume). 

Er werd dus een groot aantal bijna lege banden gebruikt om eenzelfde aan- 
tal kleine bestanden op te slaan. Om dit probleem op te lossen werden systemen 
gemaakt die meerdere bestanden op één band opslaan. Deze oplossing betekent 
een aanzienlijke verbetering van de band-gebruiksfactor, aangezien gemiddeld 10 
bestanden per band het aantal spoelen met een factor 10 vermindert. 

Nu staan we echter voor het probleem dat we moeten bepalen welke bestan- 
den op welke band staan. Dit probleem lossen we op door een inhoudsopgave (of 
adresboek) aan de band toe te voegen. In IBM-systemen wordt de band een volu- 
me genoemd en de inhoudsopgave heet Volume-Inhoudsopgave (Volume Table 
of Contents, VTOC). De inhoudsopgave registreert de naam en plaats van elk 
bestand op de band. We kunnen ook nog meer informatie over een bestand in 
het adresboek bijhouden, zoals de grootte van het bestand, wanneer het werd 
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gemaakt, enzovoort. Elke band, of elk randapparaat, heeft zijn eigen randap- 
paraatadresboek. Het adresboek van het randapparaat is een geschikte plaats om 
overzichtsinformatie bij te houden over de bestanden op dat randapparaat. 

Het opzoeken van een bestand vereist dat we de juiste band identificeren 
(dikwijls gespecificeerd door de gebruiker), zijn adresboek doorzoeken en dan de 
band positioneren op de plaats waar het bestand begint. Het lezen van het be- 
stand gaat net zo als daarvoor, toen we één bestand per band hadden, behalve 
dat de einde-van-het-bestand conditie nu verschilt van de einde-van-de-band 
conditie. We moeten ook onderscheid maken tussen het terugspoelen van het 
bestand en het terugspoelen van de band. 

Er zijn nog andere moeilijkheden. Neem een programma dat afwisselend 
regels leest van twee bestanden op dezelfde magneetband. Dan moet óf een van 
beide bestanden gekopieerd worden naar een andere band, óf de magneetband- 
eenheid zou aanzienlijke hoeveelheden tijd moeten spenderen aan het heen en 
weer bewegen tussen beide bestanden. Vergeet ook niet dat de fysieke aard van 
magneetbanden in het algemeen de mogelijkheid uitsluit van het ter plekke 
herschrijven. Dus als een bestand gewijzigd moet worden, moet de gehele band 
gekopieerd worden. Alle bestanden, ook die welke niet worden gewijzigd, moeten 
gekopieerd en herschreven worden. Het is kenmerkend dat dit zelfs nodig is als 
er een nieuw bestand wordt toegevoegd aan het einde van de band, daar voor 
bijna elke verandering het herschrijven van het adresboek vereist is. Het adres- 
boek wordt gewoonlijk aan het begin van de band bewaard om het sneller toegan- 
kelijk te maken. Dus bij wijziging van het adresboek moet de gehele band worden 
herschreven. 


3.1.3 Systemen op schijf 


Veel van de problemen die te maken hebben met het opslaan van meerdere be- 
standen op een magneetband worden opgelost wanneer een systeem wordt ge- 
bruikt op een schijf- of trommelgeheugen. Een schijf is verdeeld in sporen. Het 
aantal sporen varieert van schijfeenheid tot schijfeenheid. Ieder spoor is verder 
verdeeld in sectoren. Een sector is de kleinste hoeveelheid informatie die van de 
schijf kan worden gelezen of erop kan worden geschreven. Afhankelijk van de 
schijfeenheid variëren sectoren van 32 bytes tot 4096 bytes; er zijn 4 tot 32 sec- 
toren per spoor, en tussen de 75 en 500 sporen per schijfoppervlak. Grote schij- 
vensystemen kunnen meerdere schijven hebben (zie figuur 3.2). Elke schijf heeft 
twee oppervlakken. Om toegang tot een sector te krijgen moeten we het opper- 
vlak, het spoor, en de sector specificeren. De lees/ schrijfkoppen worden naar het 
juiste spoor bewogen (zoektijd), elektronisch naar het juiste oppervlak overge- 
schakeld, en dan moeten we wachten (wachttijd) tot de gewenste sector onder de 
koppen draait. 

Een cilinder is een groep sporen die dezelfde spoorpositie op de schijf heb- 
ben, maar zich op verschillende schijfoppervlakken bevinden. Er is geen zoektijd 
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Figuur 3.2 
Mechanisme van een schijf met bewegende koppen 


nodig voor het toegang verkrijgen tot sporen in dezelfde cilinder. 

I/O-overbrenging tussen het geheugen en de schijf heeft plaats in eenheden 
van een of meer sectoren. Voor het adresseren van een bepaalde sector is nodig 
het nummer van een spoor (of cilinder), het nummer van een oppervlak en een 
sectornummer. Zo kan de schijf worden gezien als een driedimensionale lijst van 
sectoren. Gewoonlijk wordt deze door het besturingssysteem behandeld als een 
eendimensionale lijst van schijfblokken. leder blok is een sector. Het is gebruike- 
lijk dat blokadressen oplopen met de sectoren op een spoor, vervolgens met de 
sporen in een cilinder, en tenslotte van cilinder 0 tot en met de laatste cilinder 
op de schijf. Als s het aantal sectoren per spoor is en ¢ het aantal sporen per 
cilinder, dan is het duidelijk dat we een schijfadres bestaande uit cilinder i, opper- 
vlak j en sector k, kunnen omzetten naar een 1-dimensionaal bloknummer b met 
behulp van de formule: 


b=k+sX(jtixt) 


Let erop dat met deze relatie voor het adresseren van blok b+1, als het laatst 
geadresseerde blok blok b was, alleen een zoek-operatie nodig is wanneer b het 
laatste blok van de ene cilinder en b+/ het eerste blok van de volgende cilinder 
is. Ook in dit geval wordt de kop maar over één spoor bewogen. 

Een trommelgeheugen is in feite een schijf met maar één cilinder. Daar 
ieder spoor zijn eigen lees/schrijfkop heeft, is er geen zoektijd. De belangrijkste 
verschillen tussen schijven en trommels zijn het prestatievermogen, de kosten en 
de geheugencapaciteit, niet hun logische structuur. Om die reden maken we in 
dit boek verder geen onderscheid tussen schijven en trommels. 
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Schijven en trommels verschillen van magneetbanden in twee opzichten die 
op dit moment van belang zijn. Ten eerste kan er ter plekke op worden terug- 
geschreven: het is mogelijk een blok van de schijf te lezen, het te wijzigen en het 
op dezelfde plaats terug te schrijven. Ten tweede kunnen we rechtstreeks toegang 
krijgen tot elk gegeven blok met informatie op de schijf. Het overschakelen van 
het ene bestand naar het andere vereist alleen het bewegen van de lees/ schrijfkop- 
pen en het wachten op het ronddraaien van de schijf. De combinatie van zoektijd 
en wachttijd is in het algemeen minder dan 100 milliseconden; hoewel de schijf- 
toegang niet zo snel is als die van het hoofdgeheugen, is deze veel sneller dan 
die van magneetband. Deze twee verschillen maken het veel gemakkelijker om 
meerdere bestanden op een schijf op te slaan dan op een magneetband. 

Evenals een magneetband met meerdere bestanden heeft een schijf normaal 
gesproken een adresboek dat aangeeft welke bestanden op de schijf staan. Het 
adresboek bevat een lijst van de bestanden op naam, en heeft onder meer infor- 
matie zoals waar het bestand zich bevindt op de schijf, de lengte ervan, het soort 
bestand, de eigenaar, de tijd waarop het gemaakt werd, de tijd waarop het voor 
het laatst werd gebruikt, enzovoort. Omdat blokken van de schijf ter plaatse kun- 
nen worden teruggeschreven, kunnen we het adresboek lezen, bijwerken en te- 
rugschrijven op elk moment dat dit moet worden veranderd, zonder dat we de 
rest van de schijf hoeven te kopiëren. 

leder schijvenpakket of diskette heeft zijn eigen adresboek. Dit is opgesla- 
gen op het randapparaat, vaak op een vast schijfadres, zoals schijfadres 00001. 
(Adres 00000 is gewoonlijk een zelfstartend systeem-laadprogramma.) Dit is in 
het bijzonder wenselijk voor verwisselbare opslagmedia, zoals diskettes of verwis- 
selbare schijveneenheden. Als het opslagmedium van het systeem gehaald wordt, 
opgeborgen, en dan opnieuw opgezet, misschien op een andere schijveneenheid 
of in een ander diskettestation, moeten we nog steeds de bestanden op die schijf 
of diskette kunnen vinden. 

Soms is het mogelijk een groot schijvenpakket als een verwisselbaar volume 
te gebruiken, maar de omvang (en de kosten) van zo’n schijf sluiten in het alge- 
meen dit soort gebruik uit, behalve in zeer grote systemen of als het zeer kleine 
schijven betreft. Diskettes zijn haast altijd verwisselbaar en kunnen het best be- 
handeld worden als direct-toegankelijke magneetbanden. 


3.1.4 Indeling in blokken 


Schijvensystemen hebben in de regel een duidelijk omschreven blokgrootte die 
wordt bepaald door de grootte van een sector. Alle I/O van en naar schijf gebeurt 
met een blok (fysiek record) als eenheid, en alle blokken hebben dezelfde grootte. 
Magneetbanden zijn wat flexibeler en de fysieke blokgrootte kan worden gedefi- 
nieerd door de programmatuur. Het is gebruikelijk deze vast te stellen op 80 
tekens (een kaartbeeld) per fysiek record, maar dit kan een aanzienlijke ruim- 
teverspilling betekenen als gevolg van de onbenutte ruimte tussen opeenvolgende 
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records (interrecord gaps). Een fysiek record van verscheidene duizenden bytes 
kan beter gebruik maken van magneetband. 

In elk geval is het onwaarschijnlijk, of het nu om banden gaat of schijven, 
dat de grootte van een fysiek record precies overeenkomt met de grootte van 
het gewenste logische record. Logische records kunnen zelfs in lengte variëren. 
Packing, ofwel het bundelen van een aantal logische records tot één fysiek record, 
is een veel gebruikte oplossing voor dit probleem. 

Het Unix-besturingssysteem bijvoorbeeld ziet alle bestanden per definitie 
gewoon als een stroom bytes. Elke byte is individueel adresseerbaar door zijn 
afstand (offset) gerekend vanaf het begin (of eind) van het bestand. In dit geval 
is het logische record één byte. Het bestandssysteem verzorgt automatisch de 
bundeling van bytes tot fysieke schijfblokken (zeg 512 bytes per blok) en vice 
versa, naar gelang dat noodzakelijk is. 

Kennis van de logische recordgrootte, fysieke blokgrootte en techniek van 
het bundelen bepalen hoeveel logische records gebundeld zijn tot één fysiek blok. 
De bundeling kan door het toepassingsprogramma van de gebruiker dan wel door 
het besturingssysteem worden gedaan. 

In beide gevallen kan het bestand worden beschouwd als een reeks blokken. 
Alle fundamentele I/O-bewerkingen vinden plaats op blokniveau. De omzetting 
van logische records tot fysieke blokken is een betrekkelijk eenvoudig probleem 
voor de programmatuur. 

Het altijd toewijzen van schijfruimte in blokken betekent dat in het alge- 
meen een bepaald gedeelte van het laatste blok van een bestand mogelijk niet 
benut wordt. Als elk blok 512 bytes is, worden aan een bestand van 1949 bytes 
4 blokken (2048 bytes) toegewezen; de laatste 99 bytes zouden dan onbenut blij- 
ven. Het toewijzen van niet-gebruikte bytes om alles in eenheden van blokken 
(in plaats van bytes) te houden, noemt men interne fragmentatie. Alle bestands- 
systemen hebben last van interne fragmentatie. In het algemeen zal een grotere 
blokgrootte de interne fragmentatie doen toenemen. 


3.1.5 Bestandsbewerkingen 


Bestanden kunnen worden geimplementeerd op verschillende soorten randappa- 
ratuur: magneetbanden, schijven, trommels en andere, minder gebruikelijke, op- 
slagmedia. Een bestand is een logische eenheid die een met name genoemd stuk 
informatie voorstelt. Er wordt een relatie gelegd tussen het bestand en een fysiek 
randapparaat (zie figuur 3.3). Er zijn vele manieren om deze relatie te leggen 
ofwel bestanden te te implementeren. Om de verschillende implementaties van 
bestanden te kunnen vergelijken, moeten we de definitie van bestanden begrij- 
pen, onafhankelijk van hun implementatie. Een bestand is een abstract gegevens- 
type. Om een juiste definitie te geven van een bestand, moeten we kijken naar de 
bewerkingen die op bestanden kunnen plaatsvinden. 

Een bestand is een middel voor het opslaan van informatie voor later ge- 
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Programmatuur 
Bestand — van het REN, 4 
besturingssysteem 


Fysieke 
randapparatuur 


Figuur 3.3 
Verband tussen logische bestanden en fysieke randapparatuur 


bruik. We willen (1) een bestand aanmaken en (2) naar het bestand schrijven. Op 
een later tijdstip willen we (3) het bestand terugspoelen en (4) van het bestand 
lezen. Tenslotte zullen we het bestand niet langer nodig hebben en (5) het daarom 
willen opheffen. Deze vijf bewerkingen zijn minimaal vereist voor het werken met 
bestanden. Vaker nog willen we het bestand ook opmaken/wijzigen (edit). Een 
gebruikelijke wijziging bestaat uit het toevoegen van nieuwe informatie aan het 
einde van een bestaand bestand. We kunnen een bestand kopiëren, of een kopie 
overbrengen naar een randapparaat, zoals een printer of een beeldstation. Aange- 
zien bestanden dingen zijn met een naam, is het mogelijk dat we een bestaand 
bestand een andere naam willen geven (herbenoemen). 


3.2 Bestandsondersteuning 


De implementatie van een bestand vindt plaats door het besturingssysteem. Sys- 
teemaanroepen staan de gebruiker ter beschikking om bestanden te maken, te 
schrijven, te lezen, terug te spoelen en op te heffen. Laten we, om te begrijpen 
hoe de ondersteuning van bestanden in zijn werk gaat, eens wat uitvoeriger kijken 
naar deze vijf bewerkingen. Daardoor zullen we het belang zien van het randap- 
paraatadresboek. 


3.2.1 Bestandsbewerkingen 


Neem voor het gemak aan dat het bestandssysteem op schijf staat. Laten we eens 
zien wat het besturingssysteem voor elk van de vijf fundamentele bewerkingen 
moet doen. Dan moet het niet al te moeilijk zijn te begrijpen hoe soortgelijke 
bewerkingen, zoals het herbenoemen van een bestand, geïmplementeerd worden. 


@ Het aanmaken van een bestand. Er zijn twee stappen nodig om een bestand te 
maken. Ten eerste moet er in het bestandssysteem ruimte worden gevonden 
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voor het bestand. In paragraaf 3.4 wordt besproken hoe ruimte voor het nieu- 
we bestand kan worden toegewezen. Ten tweede moet er voor het bestand een 
ingang worden gemaakt in het adresboek. Deze ingang legt de naam van het 
bestand evenals zijn plaats in het bestandssysteem vast. 

@ Het schrijven naar een bestand. Om naar een bestand te schrijven wordt er een 
systeemaanroep gedaan, die de naam van het bestand specificeert en ook de 
informatie die naar het bestand moet worden geschreven. Met de naam van 
het bestand als gegeven zoekt het systeem in het adresboek de plaats van het 
bestand op. In de ingang van het adresboek moet een wijzer worden opgebor- 
gen naar het momentele einde van het bestand. Met gebruikmaking van deze 
wijzer kan het adres van het volgende blok worden berekend en kan de infor- 
matie worden weggeschreven. De schrijfwijzer moet worden bijgewerkt. Op 
deze manier kunnen achtereenvolgende schrijfbewerkingen worden gebruikt 
om een reeks blokken naar het bestand te schrijven. 

@ Het lezen van een bestand. Voor het lezen van een bestand specificeert een 
systeemaanroep de naam van het bestand en de plaats waar (in het geheugen) 
het volgende blok van het bestand moet worden gezet. Opnieuw wordt in het 
adresboek de bijbehorende adresboekingang opgezocht. Ook nu heeft deze in- 
gang een wijzer nodig voor het lezen van het volgende blok. Is dat blok gelezen, 
dan wordt de wijzer bijgewerkt. 

In het algemeen wordt een bestand óf gelezen óf er wordt naar geschre- 
ven. Daarom hebben de meeste systemen, hoewel het mogelijk zou zijn twee 
wijzers te hebben: een leeswijzer en een schrijfwijzer, er slechts één, een mo- 
mentele bestandspositie. Zowel de lees- als de schrijfbewerking gebruiken deze 
zelfde wijzer, waardoor ruimte bespaard wordt in de adresboekingang en de 
complexiteit van het systeem wordt verminderd. 

@ Het terugspoelen van een bestand. Het terugspoelen van een bestand hoeft niet 
gepaard te gaan met werkelijke I/O. Eigenlijk gezegd wordt de juiste ingang 
in het adresboek opgezocht en de momentele bestandspositie teruggezet op 
het begin van het bestand. 

e Het opheffen van een bestand. Om een bestand op te heffen zoeken we in het 
adresboek naar het benoemde bestand. Wanneer we de juiste ingang gevonden 
hebben, geven we alle bestandsruimte vrij (zodat deze opnieuw kan worden 
gebruikt door andere bestanden) en maken we de adresboekingang ongeldig. 


U zult hebben opgemerkt dat bij al de vermelde bewerkingen de ingang in 
het adresboek wordt opgezocht die hoort bij het benoemde bestand. Deze ingang 
bevat al de belangrijke informatie die nodig is om bestandsbewerkingen te doen. 
Om al dit zoeken te voorkomen openen vele systemen een bestand, zodra dit 
actief gebruikt gaat worden, Het besturingssysteem houdt een kleine tabel bij die 
informatie aangaande alle open bestanden bevat. Wanneer een bestandsbewer- 
king wordt aangevraagd, wordt alleen deze kleine tabel doorzocht, niet het gehele 
adresboek. Wordt het bestand niet langer actief gebruikt, dan wordt het gesloten 
en uit de tabel van de open bestanden verwijderd. 
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Sommige systemen openen een bestand impliciet wanneer de eerste verwij- 
zing ernaar wordt gemaakt. Het bestand wordt automatisch gesloten wanneer de 
job of het programma dat het bestand opende beëindigd wordt. De meeste syste- 
men vereisen echter dat een bestand expliciet door de programmeur met een 
systeemaanroep (open) wordt geopend voor het kan worden gebruikt. De open- 
bewerking neemt de naam van het bestand, zoekt de ingang in het adresboek op 
en kopieert deze in de tabel van open bestanden. Dan zal de open-aanroep meest- 
al een wijzer teruggeven die wijst naar de ingang in deze tabel. Deze wijzer, en 
niet de werkelijke bestandsnaam, wordt bij alle 1/O-bewerkingen gebruikt, waar- 
door verder zoeken wordt vermeden. 


3.2.2 Randapparaatadresboek 


De speciale informatie die voor ieder bestand in het adresboek wordt bewaard 
verschilt van besturingssysteem tot besturingssysteem. Nu volgt een lijst van in- 
formatie die in de ingang van een adresboek kan worden bewaard. Niet alle syste- 
men bewaren natuurlijk al deze informatie. 


@ Bestandsnaam. De symbolische bestandsnaam. 

@ Bestandssoort. Voor die systemen die verschillende bestandssoorten onder- 
steunen. 

@ Plaats. Een wijzer naar het randapparaat en de plaats van het bestand daarop. 

@ Grootte. De momentele grootte van het bestand (in bytes, woorden of blok- 
ken) en de maximaal toegestane grootte. 

@ Momentele positie. Een wijzer naar de momentele lees- of schrijfpositie in het 
bestand. 

@ Beveiliging. Toegangsbeheer-informatie om het lezen, schrijven, enzovoort, te 
besturen. 

@ Gebruikstelling. Geeft het aantal processen aan die op het moment dat bestand 
gebruiken (geopend hebben). 

@ Tijd, datum en proces-identificatie. Deze informatie kan worden bewaard voor 
(a) aanmaken, (b) laatste wijziging, en (c) laatste gebruik. Dit kan nuttig zijn 
met het oog op beveiliging en gebruiksregistratie. 


Er kunnen 16 tot meer dan 1000 bytes nodig zijn om deze informatie voor elk 
bestand vast te leggen. In een systeem met een groot aantal bestanden kan de 
omvang van het adresboek alleen al honderdduizenden bytes zijn. Daarom kan 
het nodig zijn dat het randapparaatadresboek wordt opgeslagen op het randappa- 
raat en bij stukjes en beetjes in het geheugen wordt gebracht, al naar behoefte. 

Als we het adresboek zien als een symbolentabel voor het vertalen van be- 
standsnamen naar hun ingangen in het adresboek, wordt het duidelijk dat het 
adresboek zelf op tal van manieren kan worden georganiseerd. We willen ingan- 
gen kunnen toevoegen, verwijderen, opzoeken en alle ingangen in het adresboek 
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kunnen uitlijsten. Welke gegevensstructuur wordt voor het adresboek gebruikt? 

Een lineaire lijst van adresboekingangen vereist een lineaire opzoekpro- 
cedure om een bepaalde ingang te vinden. Dit is eenvoudig te programmeren 
maar de uitvoering is tijdrovend. Voor het maken van een nieuw bestand moeten 
we eerst het adresboek doorzoeken om zeker te weten dat geen bestaand bestand 
dezelfde naam heeft. Voor het opheffen van een bestand zoeken we in het adres- 
boek het bestand met deze naam en geven dan de ruimte die eraan toegewezen 
is vrij. Om de adresboekingang opnieuw te gebruiken kunnen we op verschillende 
manieren te werk gaan. We kunnen deze als niet-gebruikt aanmerken (door mid- 
del van een blanco naam, of een in-gebruik/niet-in-gebruik bit in elke ingang), 
of de ingang in een lijst opnemen met vrije adresboekingangen. Een derde mo- 
gelijkheid is de laatste ingang in het adresboek naar de vrijgegeven plaats te 
kopiëren en de lengte van het adresboek met één te verminderen. Men kan ook 
van een verbonden lijst gebruik maken om de tijd nodig voor het opheffen van 
een bestand te bekorten. 

Het werkelijke nadeel van een lineaire lijst van adresboekingangen is de 
lineaire zoekprocedure voor het vinden van een bestand. Met een gesorteerde lijst 
is een binaire zoekprocedure mogelijk. Het zoekalgoritme is evenwel ingewikkel- 
der te programmeren. Bovendien moet de lijst gesorteerd worden gehouden. Deze 
eis kan het maken en opheffen van bestanden gecompliceerd maken, aangezien 
we misschien aanzienlijke hoeveelheden adresboekinformatie moeten opschuiven 
om aan een gesorteerd adresboek vast te houden. (Let er echter op dat, als we 
een lijst willen kunnen produceren van alle bestanden gesorteerd op bestands- 
naam, we niet nog eens weer hoeven te sorteren voor het uitlijsten.) Een aaneen- 
geschakelde binaire boom zou hier kunnen helpen. 

Nog een gegevensstructuur die wel gebruikt is voor een bestandsadresboek 
is een hash-tabel. (Hashing is het omrekenen met behulp van een bepaald algo- 
ritme, de zogenoemde ’hash-functie’, van de naam van een bestand tot een getal, 
dat dan wordt gebruikt als het nummer van de ingang in het adresboek — Vert.) 
De gegevensstructuur van een hash-tabel kan de zoektijd door het adresboek 
aanzienlijk verbeteren. Invoegen en verwijderen gaan ook tamelijk eenvoudig, 
hoewel er een voorziening moet zijn voor botsingen — situaties waarin twee be- 
standsnamen een code genereren die op dezelfde plaats in de tabel uitkomt. De 
voornaamste moeilijkheden met een hash-tabel zijn de grootte van de tabel, die 
over het algemeen vastligt, en het feit dat de hash-functie afhangt van de grootte 
van de hash-tabel. 

Stel dat we werken met een hash-tabel van 64 ingangen. De hash-functie 
zet de bestandsnaam om in gehele getallen van 0 tot en met 63, waarschijnlijk 
door een eindbewerking waarbij de rest van de deling door 64 wordt gebruikt. 
Als we nu later proberen een 65ste bestand te maken moeten we de hash-tabel 
groter maken, zeg 100 ingangen. Als gevolg daarvan hebben we een nieuwe hash- 
functie nodig die de bestandsnamen moet afbeelden op het interval 0 tot en met 
99, en moeten we de bestaande adresboekingangen reorganiseren om deze te la- 
ten overeenstemmen met hun nieuwe hash-waarden. 
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3.3 Toegangsmethoden 


Bestanden dienen voor het opslaan van informatie. Wanneer deze informatie 
wordt gebruikt, moet deze toegankelijk worden gemaakt en in het computer- 
geheugen worden ingelezen. Er zijn verschillende manieren om de informatie in 
het bestand toegankelijk te maken. Sommige systemen hebben slechts één toe- 
gangsmethode voor bestanden, dus dan is het begrip ’toegangsmethoden’ niet 
belangrijk. Door andere systemen, zoals die van IBM, worden diverse toegangs- 
methoden ondersteund en het kiezen van de juiste voor een speciale toepassing 
is dan een ontwerpprobleem van de eerste orde. 


3.3.1 Sequentiële toegang 


Het merendeel van de bestandsbewerkingen bestaat uit lees- en schrijfbewerkin- 
gen. Een leesbewerking leest het volgende gedeelte van het bestand en werkt auto- 
matisch de wijzer bij. Op dezelfde wijze voegt een schrijfbewerking informatie 
toe aan het einde van het bestand en werkt deze de wijzer bij zodat die wijst 
naar het einde van het nieuw bijgeschreven materiaal (het nieuwe einde van het 
bestand). Zo’n bestand kan worden teruggespoeld, en op sommige systemen is 
het mogelijk dat een programma zowel in voor- als in achterwaartse richting n 
records overslaat, waarbij n een geheel getal is (misschien alleen voor n = 1). 
Deze opzet staat bekend als sequentiële toegang tot een bestand (zie figuur 3.4). 
Sequentiële toegang is gebaseerd op het magneetband-model van een bestand. 


3.3.2 Directe toegang 


Een andere toegangsmethode is directe toegang, gebaseerd op bestanden op schijf. 
Voor directe toegang wordt het bestand gezien als een genummerde reeks record- 
blokken. Een blok is in het algemeen een grootheid met een vaste lengte, die door 
het besturingssysteem gedefinieerd is als de minimale eenheid voor positioneren 
(zie figuur 3.5). Een blok kan een byte zijn, 512 woorden, 1024 bytes, of een 


momentele positie 


begin eind 


+—_—_——terugspoelen—_———____ 
lezen of schrijven—» 


Figuur 3.4 
Bestand met sequentiële toegang 
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blok 0 blok 1 blok 2 blok n blok n+1 


Figuur 3.5 
Bestand met directe toegang 


andere grootheid, afhankelijk van het systeem. Bij sommige systemen is het mo- 
gelijk de blokgrootte voor ieder bestand afzonderlijk te definiéren. 

In een direct-toegankelijk bestand kunnen willekeurige blokken worden ge- 
lezen of geschreven. Zo kunnen we blok 14 lezen, daarna blok 53, en dan blok 7 
schrijven. Er gelden voor een direct-toegankelijk bestand geen meen met 
betrekking tot de volgorde van lezen of schrijven. 

Bestanden met directe toegang zijn van groot nut voor de onmiddellijke 
toegang tot grote hoeveelheden informatie. Ze worden dikwijls gebruikt bij het 
zoeken in grote gegevensbanken. Wanneer een verzoek om informatie over een 
belangrijk onderwerp binnenkomt, berekenen we welk blok het antwoord bevat 
en lezen dan rechtstreeks dat blok om de gewenste informatie te krijgen. 

In een luchtvaartreserveringssysteem bijvoorbeeld, zouden we alle informa- 
tie over een bepaalde vlucht (laten we zeggen vlucht 713) kunnen opslaan in het 
blok dat hetzelfde nummer heeft als het vluchtnummer. Dus het aantal beschik- 
bare plaatsen voor vlucht 713 is opgeslagen in blok 713 van het reserveringsbe- 
stand. Om informatie over een grotere groep, zoals mensen, op te slaan, zouden 
we een hash-functie kunnen berekenen voor hun naam, of in een klein adresboek 
in het hoofdgeheugen zoeken om het blok vast te stellen dat we dan moeten 
inlezen en doorzoeken. 

De bestandsbewerkingen moeten worden gewijzigd om het bloknummer als 
een parameter mee te kunnen geven. Zo hebben we dan lees n, waarin n het 
bloknummer is, in plaats van lees volgende, en schrijf n in plaats van schrijf volgen- 
de. Een andere manier is dat we lees volgende en schrijf volgende aanhouden, zoals 
bij sequentiële toegang, en een bewerking toevoegen: positioneer bestand op n, 
waarin n het bloknummer is. Dan wordt het effect van lees n bereikt door positio- 
neer bestand op n gevolgd door lees volgende. 

Het bloknummer zoals dat door de gebruiker aan het besturingssysteem 
wordt aangeboden is gewoonlijk een relatief bloknummer. Een relatief bloknum- 
mer is een index, of afstand, gerekend vanaf het begin van het bestand. Zo is het 
relatieve bloknummer van het eerste blok van het bestand 0, dat van het volgende 
1, enzovoort, ook al kan het werkelijke absolute adres op schijf wel blok 14703 
zijn voor het eerste blok, en 14704 voor het tweede blok. Het gebruik van relatieve 
bloknummers geeft het besturingssysteem de mogelijkheid te beslissen waar het 
bestand geplaatst moet worden (het toewijzingsprobleem zoals dat hierna bespro- 
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ken wordt in paragraaf 3.4), en draagt ertoe bij te voorkomen dat de gebruiker 
toegang heeft tot gedeelten van het bestandssysteem die niet tot zijn bestand 
behoren. Sommige systemen beginnen hun relatieve bloknummering bij 0, andere 
beginnen bij 1. 

Niet alle besturingssystemen geven ondersteuning voor zowel sequentiële 
als directe toegang voor bestanden. Sommige systemen hebben alleen sequentiële 
bestandstoegang; andere staan alleen directe toegang toe. Sommige systemen ver- 
eisen dat een bestand wordt gedefinieerd als sequentieel of direct-toegankelijk 
wanneer het bestand wordt gemaakt; tot zo’n bestand kan alleen toegang worden 
verkregen op een manier die strookt met de wijze waarop het bestand is gedecla- 
reerd. Let er evenwel op dat het heel gemakkelijk is sequentiële toegang te simule- 
ren voor een direct-toegankelijk bestand. Als we eenvoudigweg een variabele mp 
bijhouden die onze momentele positie aangeeft, dan kunnen we sequentiële be- 
standsverwerking simuleren als aangegeven in figuur 3.6. Aan de andere kant is 
het uitermate inefficiënt en onhandig een direct-toegankelijk bestand te simule- 
ren voor een sequentieel bestand. 


3.3.3 Andere toegangsmethoden 


Andere toegangsmethoden kunnen worden gebouwd met de directe-toegangme- 
thode als basis. Deze extra methoden brengen gewoonlijk de constructie van een 
_ index voor het bestand met zich. De index, evenals de index achterin een boek, 

bevat wijzers naar de verschillende blokken. Om een ingang in het bestand te 
vinden zoeken we eerst in de index en gebruiken dan de wijzer voor directe toe- 
gang tot het bestand en het vinden van de gewenste ingang. 

Een voorbeeld wordt gegeven door een bestand met winkelprijzen dat de 
Universele Produkt Code (UPC) voor artikelen bevat tezamen met hun prijs. 
Elke ingang bestaat uit een UPC-code van tien cijfers en een prijs van zes cijfers, 
een ingang dus van 16 bytes. Als onze schijf 1024 bytes per blok heeft, kunnen 
we 64 ingangen per blok opslaan. Een bestand van 120.000 ingangen zou dan 


Sequentiële toegang Implementatie bij 
directe toegang 
spoel terug mp := 0; 
lees volgende lees blok mp; 
mp := mp+1; 
schrijf volgende schrijf blok mp; 
mp := mp+1; 


Figuur 3.6 
Simulatie van sequentiéle toegang op een direct-toegankelijk bestand 
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ongeveer 2000 blokken (2 miljoen bytes) in beslag nemen. Door het bestand op 
UPC-code gesorteerd te houden, kunnen we een index definiëren bestaande uit 
de eerste UPC-code van elk blok. Deze index heeft dan 2000 ingangen van elk 
tien cijfers, ofwel 20.000 bytes, en kan in het geheugen opgeslagen worden. Om 
de prijs van een artikel te vinden kunnen we de index (binair) doorzoeken. Dit 
heeft dan tot resultaat dat we precies weten welk blok de gewenste ingang bevat 
en we kunnen dat blok dan adresseren. Deze structuur stelt ons in staat een groot 
bestand te raadplegen met heel weinig I/O. 

Met grote bestanden kan het indexbestand zelf te groot worden om dit in 
het geheugen te houden. Een oplossing is dan dat we een index maken voor 
het indexbestand. Het primaire indexbestand bevat dan wijzers naar secundaire 
indexbestanden, die op hun beurt wijzen naar de echte gegevenselementen. 

ISAM (Indexed Sequential Access Method) van IBM bijvoorbeeld maakt 
gebruik van een kleine hoofdindex die wijst naar schijfblokken van een secundai- 
re index (zie figuur 3.7). De blokken van de secundaire index wijzen naar de 
blokken van het werkelijke bestand. Het bestand wordt gesorteerd gehouden op 
een vastgestelde sleutel (key). Om een bepaald gegeven te vinden wordt eerst een 
binair zoekproces ondernomen op de hoofdindex, wat het bloknummer oplevert 
van de secundaire index. Dit blok wordt ingelezen, en nogmaals wordt een binair 
zoekproces ondernomen, nu om het blok te vinden met het gewenste record. 
Tenslotte wordt het blok sequentieel doorzocht. Op deze manier kan elk record 
met behulp van zijn sleutel in ten hoogste twee directe-toegang leesbewerkingen 
worden gevonden. Het opzoeken van 5-81 bijvoorbeeld, zou kunnen vereisen het 
lezen van blok 7 van de secundaire index, en dan blok 494 van het hoofdbestand. 


3.4 Toewijzingsmethoden 


Vanuit het gezichtspunt van de gebruiker is een bestand een abstract gegevens- 
type. Het kan worden gemaakt, geopend, geschreven, teruggespoeld, gelezen, ge- 
sloten en opgeheven, zonder dat hij, de gebruiker, zich druk hoeft te maken over 
de implementatie daarvan. De implementatie van een bestand is een probleem 
voor het besturingssysteem. 

In een systeem op magneetband is de implementatie van bestanden vrij 
eenvoudig, vanwege de fysieke beperkingen van het opslagmedium. We kunnen 
óf elk bestand relateren aan een afzonderlijke magneetband óf verschillende be- 
standen aan eenzelfde band. Alleen sequentiële toegang kan redelijkerwijs wor- 
den ondersteund. 

Het directe-toegangskarakter van schijven geeft ons meer flexibiliteit in de 
implementatie van bestanden. In bijna alle gevallen zullen veel bestanden worden 
opgeslagen op dezelfde schijf. Het hoofdprobleem is hoe ruimte aan deze bestan- 
den moet worden toegewezen zodat de ruimte op de schijf effectief wordt benut 
en men snel toegang heeft tot de bestanden. Er zijn drie hoofdmethoden voor 
het toewijzen van schijfruimte die wijd en zijd worden gebruikt: aaneengesloten, 
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Figuur 3.7 
Bestandsstructuur in ISAM (Indexed Sequential Access Method; geïndiceerd-sequentiële 
toegangsmethode) 
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aaneengeschakeld, en geïndiceerd. Elk van deze methoden heeft zijn voor- en na- 
delen. Daarom geven sommige systemen (zoals RDOS van Data General voor 
de computers van hun Nova-serie) ondersteuning aan alle drie. Het komt echter 
meer voor dat een systeem voor alle bestanden gebruik maakt van één bepaalde 
methode. 


3.4.1 Het beheer van vrije ruimte 


Tijdens de werking van een computersysteem worden er dikwijls bestanden ge- 
maakt en opgeheven. Aangezien er slechts een beperkte ruimte op schijf is, is het 
noodzakelijk de ruimte van opgeheven bestanden weer te gebruiken voor nieuwe 
bestanden. Om de vrije schijfruimte in het oog te houden houdt het systeem een 
vrije-ruimtelijst bij. De vrije-ruimtelijst legt vast welke schijfblokken vrij zijn (dat 
wil zeggen niet toegewezen aan een of ander bestand). Voor het maken van een 
bestand zoeken we de vrije-ruimtelijst door om te zien of er genoeg ruimte be- 
schikbaar is en wijzen deze dan toe aan het nieuwe bestand. Deze ruimte wordt 
dan verwijderd uit de vrije-ruimtelijst. Wanneer een bestand opgeheven wordt, 
wordt zijn schijfruimte aan de vrije-ruimtelijst toegevoegd. 

Ondanks zijn naam hoeft de vrije-ruimtelijst in de praktijk niet als een lijst 
te zijn opgezet. Dikwijls wordt hij opgezet als een bittabel of bitvector. Elk blok 
wordt gerepresenteerd door een bit. Is het blok vrij, dan is de bit 0; is het blok 
toegekend, dan is de bit 1. Neem bijvoorbeeld een schijf waarop de blokken 2, 
3, 4, 5, 8, 9, 10, 11, 12, 13, 17, 18, 25, 26 en 27, vrij zijn. Dan zou de vrije- 
ruimtebittabel er zo uitzien: 


1100001 10000001 110011111100011111 … 


Een andere aanpak is het aaneenschakelen van alle vrije schijfblokken, 
waarbij een wijzer altijd naar het eerste vrije blok wijst. Dit blok bevat een wijzer 
naar het volgende vrije blok, enzovoort. In ons voorbeeld zouden we een wijzer 
kunnen laten wijzen naar blok 2 als het eerste blok dat vrij is. Blok 2 zou dan 
een wijzer bevatten die naar blok 3 wijst, dat op zijn beurt wijst naar blok 5, dat 
wijst naar blok 8, enzovoort (zie figuur 3.8). 

Deze methode is niet erg efficiënt, omdat we voor het doorlopen van de 
lijst elk blok moeten lezen, hetgeen een aanzienlijke tijd voor I/O vereist. Een 
variant op deze aanpak is het opslaan van de adressen van de eerste n vrije blok- 
ken in het eerste vrije blok. De eerste n-1 daarvan zijn echt vrij. Het laatste adres 
is het adres van een tweede blok dat de adressen van weer n vrije blokken bevat. 
Het belang van deze implementatie is hierin gelegen dat de adressen van een 
groot aantal vrije blokken snel kunnen worden gevonden. 

Weer een andere aanpak komt tot stand door profijt te trekken uit het feit 
dat, in het algemeen, diverse aangrenzende blokken tegelijkertijd kunnen worden 
toegewezen of vrijgegeven, met name wanneer de methode van de aaneengesloten 
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Figuur 3.8 
Aaneengeschakelde vrije-ruimtelijst op schijf 


toewijzing (paragraaf 3.4.2) wordt gebruikt. Dus, in plaats van een lijst bij te 
houden van n vrije schijfadressen, kunnen we het adres van het eerste vrije blok 
bewaren alsmede het aantal n van de aangrenzende blokken die daarop volgen. . 
Elk element van de vrije-ruimtelijst bestaat dan uit een schijfadres en een aantal. 
Ook al hebben we nu voor elk element afzonderlijk meer ruimte nodig dan die 
voor een enkel schijfadres, de lijst als geheel zal korter zijn zolang het aantal 
opeenvolgende vrije blokken in het algemeen maar groter is dan één. 


3.4.2 Aaneengesloten toewijzing 
De methode van aaneengesloten toewijzing vereist dat ieder bestand een groep 


aangrenzende schijfadressen in beslag neemt. Schijfadressen bepalen een lineaire 
ordening. Let erop dat voor het verkrijgen van toegang tot blok b+1 na blok b 
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met deze volgorde gewoonlijk geen armbeweging vereist is. Is er al een armbewe- 
ging nodig (van de laatste sector van een cilinder naar de eerste sector van de 
volgende cilinder), dan is dit slechts over één spoor. 

Aaneengesloten toewijzing van een bestand wordt bepaald door het schijf- 
adres van het eerste blok en de lengte van het bestand. Als het bestand n blok- 
ken lang is en begint op plaats b, dan neemt het de blokken b, b+1, b+2, ..., 
b + n—1 in beslag. De adresboekingang voor elk bestand geeft dan het adres aan 
van het beginblok en de lengte van het gebied die aan dit bestand zijn toegewezen 
(zie figuur 3.9). 

De toegankelijkheid van een bestand met aaneengesloten toewijzing is vrij 
gemakkelijk. Voor sequentiéle toegang herinnert het bestandssysteem zich het 
schijfadres van het laatste blok en leest, zo nodig, het volgende blok. Voor directe 
toegang tot blok i van een bestand dat begint bij blok b, hebben we onmiddellijk 
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toegang tot blok b+i. Dus zowel sequentiële als directe toegang kunnen worden 
ondersteund door aaneengesloten toewijzing. 

De moeilijkheid met aaneengesloten toewijzing is het vinden van ruimte 
voor een nieuw bestand. Wanneer eenmaal de implementatie van de vrije-ruimte- 
lijst is gedefinieerd, kunnen we besluiten hoe we vrije ruimte moeten vinden voor 
een bestand met aaneengesloten toewijzing. Als het bestand dat moet worden 
gemaakt n blokken lang is, moeten we de vrije-ruimtelijst doorzoeken op n vrije 
aaneengrenzende blokken. In het geval van een bittabel moeten we n 0-bits op 
een rijtje vinden; in het geval van een lijst met adressen en aantallen, een aantal 
van tenminste n. Dit probleem kan dan worden gezien als een speciaal geval van 
het algemene probleem van dynamische geheugentoewijzing. 


Dynamische geheugentoewijzing 

Schijfruimte kan worden gezien als een grote reeks schijfblokken. Op elk moment 
zijn sommige van deze blokken aan bestanden toegewezen en andere zijn vrij. 
Schijfruimte kan aldus worden gezien als een verzameling vrije en gebruikte seg- 
menten; elk segment is een aaneengesloten groep schijfblokken. Een niet aan een 
bestand toegewezen segment noemt men een gat. Het probleem van dynamische 
geheugentoewijzing is: hoe kunnen we aan een verzoek voor n blokken voldoen 
met behulp van een lijst van gaten. Er zijn vele oplossingen voor dit probleem. 
De groep gaten wordt doorzocht om te bepalen welk gat het beste kan worden 
toegewezen. De meest gebruikelijke strategieën voor het selecteren van een gat 
uit de groep van beschikbare gaten zijn: eerst-passend, best-passend en slechtst- 
passend. 


@ Eerst-passend. Wijs het eerste gat toe dat groot genoeg is. Het zoeken kan 
beginnen óf aan het begin van de groep gaten óf op de plaats waar de laatste 
keer het zoeken eindigde. We kunnen ophouden met zoeken zodra we een gat 
vinden dat groot genoeg is. 

@ Best-passend. Wijs het kleinste gat toe dat groot genoeg is. We moeten de 
gehele lijst doorzoeken, tenzij de lijst gesorteerd op grootte wordt bijgehouden. 
Deze strategie levert het kleinste gat op dat over is. 

@ Slechtst-passend. Wijs het grootste gat toe. Ook nu moeten we de gehele lijst 
doorzoeken, tenzij deze gesorteerd is op grootte. Deze strategie levert het 
grootste gat op dat over is, hetgeen nuttiger kan zijn dan het kleinste gat dat 
over is, geleverd door een best-passend-aanpak. 


Simulatiestudies hebben aangetoond dat zowel eerst-passend als best-passend be- 
ter zijn dan slechtst-passend, zowel wat betreft tijd als het benutten van geheu- 
genruimte. Noch eerst-passend noch best-passend is duidelijk de beste strategie 
uit het oogpunt van het benutten van geheugenruimte, maar eerst-passend is 
uiteraard sneller. 

Deze algoritmen lijden aan externe fragmentatie. Bij het maken en opheffen 
van bestanden wordt de vrije schijfruimte opgebroken in kleine stukjes. Externe 
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fragmentatie treedt op wanneer er voldoende schijfruimte is om aan een verzoek 
te voldoen, maar die ruimte niet aaneengesloten is; de geheugenruimte wordt in 
een groot aantal kleine gaten opgebroken (gefragmenteerd). Afhankelijk van de 
totale hoeveelheid schijfruimte en de gemiddelde bestandsgrootte kan externe 
fragmentatie een klein of een groot probleem zijn. 


Comprimeren 

Sommige microcomputersystemen gebruiken aaneengesloten toewijzing voor 
diskette-bestanden. Om te voorkomen dat aanzienlijke hoeveelheden schijfruimte 
verloren gaan aan externe fragmentatie, moet de gebruiker een comprimerings- 
routine draaien, die in feite het gehele bestandssysteem kopieert naar een andere 
diskette of magneetband. De oorspronkelijke diskette wordt dan volledig vrijge- 
maakt, waardoor een groot gat (reeks aaneengesloten vrije blokken) ontstaat. 
De bestanden kunnen dan terug worden gekopieerd naar de diskette, waarbij 
aaneengesloten ruimte wordt toegewezen afkomstig van dit ene grote gat. Dit 
procédé comprimeert in feite alle vrije ruimte tot één gat, waarmee het fragmen- 
tatieprobleem wordt opgelost. De prijs die men voor dit comprimeren betaalt is 
tijd. Het kopiëren van alle bestanden op een schijf om ruimte te comprimeren 
kan uren duren en kan wel wekelijks nodig zijn. 


Problemen met aaneengesloten toewijzing 

Er zijn andere problemen met aaneengesloten toewijzing. Het voornaamste pro- 
bleem is het bepalen hoeveel ruimte voor een bestand nodig is. Wanneer het 
bestand wordt gemaakt, moet de totale hoeveelheid ruimte die het nodig zal heb- 
ben worden gevonden en toegewezen: maak een bestand van n blokken. Hoe 
weet de gebruiker (programma of persoon) de grootte van het bestand dat ge- 
maakt moet worden? In sommige gevallen kan het bepalen daarvan vrij eenvou- 
dig zijn (bij het kopiëren van een bestaand bestand bijvoorbeeld), maar in het 
algemeen kan het heel moeilijk zijn de grootte van een uitvoerbestand te schatten. 

Als we te weinig ruimte aan een bestand toewijzen, kunnen we mogelijk 
ontdekken dat deze ruimte niet kan worden uitgebreid. Speciaal in geval van een 
best-passend-strategie kan de ruimte aan weerskanten van het bestand in gebruik 
zijn. We kunnen het bestand eenvoudig niet groter maken. Dan zijn er twee mo- 
gelijkheden. Ten eerste kan het gebruikersprogramma worden beëindigd, met ge- 
bruikmaking van een geschikte foutmelding. De gebruiker moet dan meer ruimte 
(laten) toewijzen en het programma opnieuw draaien. Dit herhaald draaien kan 
zeer kostbaar zijn. Om dat te vermijden zal de gebruiker meestal een te grote 
schatting opgeven van de benodigde ruimte, hetgeen tot gevolg heeft dat heel wat 
ruimte wordt verspild. 

De andere mogelijkheid is een groter gat te vinden, de inhoud van het be- 
stand naar de nieuwe ruimte te kopiëren en de vorige ruimte vrij te geven. Deze 
handeling kan zolang er ruimte bestaat worden herhaald, al kan dit heel tijdro- 
vend zijn. Let er echter op dat in dit geval de gebruiker nooit expliciet in kennis 
hoeft te worden gesteld van wat er gaande is; het systeem gaat ondanks het pro- 
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bleem door, zij het langzamer en langzamer. 

Zelfs indien de totale hoeveelheid voor een bestand benodigde ruimte van 
tevoren bekend is, kan het inefficiënt zijn deze van tevoren toe te wijzen. Een 
bestand dat langzaam over een lange tijdsperiode (maanden of jaren) groeit, moet 
voldoende ruimte toegewezen krijgen voor zijn uiteindelijke grootte, zelfs al 
wordt veel van die ruimte lange tijd misschien niet gebruikt. 


34.3 Aaneengeschakelde toewijzing 


De hiervoor besproken problemen kunnen rechtstreeks worden teruggevoerd tot 
de eis dat ruimte aaneengesloten moet worden toegewezen. Met aaneengeschakel- 
de toewijzing worden deze problemen opgelost. Aaneengeschakelde toewijzing wil 
zeggen dat ieder bestand is opgebouwd uit een aaneengeschakelde lijst van schijf- 
blokken, die zelf overal over de schijf verspreid kunnen liggen. Het adresboek 
bevat een wijzer naar het eerste (en één naar het laatste) blok van het bestand. 
Bijvoorbeeld, een bestand van 5 blokken, beginnend bij blok 9, kan verder gaan 
bij blok 16, dan blok 1, blok 10, en tenslotte blok 25 (zie figuur 3.10). Elk blok 
bevat een wijzer naar het volgende blok. Deze wijzers worden niet ter beschikking 
gesteld van de gebruiker. Dus als elke sector uit 512 woorden bestaat, en een 
schijfadres (de wijzer) twee woorden nodig heeft, ziet de gebruiker blokken van 
510 woorden. 

Het aanmaken van een bestand is gemakkelijk; we maken gewoon een nieu- 
we ingang in het randapparaatadresboek. Bij aaneengeschakelde toewijzing heeft 
elke adresboekingang een wijzer naar het eerste blok van het bestand. Deze wijzer 
krijgt de aanvangswaarde nul (de eind-van-de-lijst wijzerwaarde) om aan te geven 
dat het bestand leeg is. Een schrijfbewerking naar het bestand neemt het eerste 
vrije blok van de vrije-ruimtelijst af en schrijft ernaar. Dit nieuwe blok wordt 
dan aan het einde van het bestand geschakeld. Om het bestand te lezen, lezen we 
gewoon de blokken door de wijzers van blok tot blok te volgen. 

Bij aaneengeschakelde toewijzing treedt er geen externe fragmentatie op. 
Elk vrij blok op de vrije-ruimtelijst kan gebruikt worden om aan het verzoek te 
voldoen, aangezien alle blokken aaneengeschakeld zijn. Let erop dat het ook niet 
nodig is de grootte van het bestand op te geven wanneer het bestand wordt ge- 
maakt. Een bestand kan blijven groeien zolang er vrije blokken zijn. Dienten- 
gevolge is het nooit nodig schijfruimte te comprimeren. 

Aaneengeschakelde toewijzing heeft echter ook nadelen. Het belangrijkste 
probleem is dat deze methode alleen effectief kan worden gebruikt voor sequen- 
tieel-toegankelijke bestanden. Om het i-de blok van een bestand te vinden moe- 
ten we beginnen bij het begin van dat bestand en de wijzers volgen tot we bij het 
i-de blok komen. Elke toegang tot een wijzer vereist een schijf-leesbewerking. 
Vandaar dat we geen directe toegankelijkheid kunnen ondersteunen voor bestan- 
den met aaneengeschakelde toewijzing. 

Een ander nadeel verbonden aan aaneengeschakelde toewijzing is de ruimte 
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Figuur 3.10 
Aaneengeschakelde toewijzing van schijfruimte 


die nodig is voor de wijzers. Als een wijzer twee bytes vereist van een blok van 
256 bytes, dan is 2,3% van de schijf in gebruik voor wijzers, niet voor informatie. 
Elk bestand heeft daarom iets meer ruimte nodig. 

Een subjectiever probleem is betrouwbaarheid. De bestanden zijn aaneen- 
geschakeld met wijzers die over de schijf verspreid zijn. Denk eens aan wat er 
zou gebeuren als er een wijzer verloren gaat of beschadigd wordt. Een fout in de 
programmatuur van het besturingssysteem of een apparatuurfout van de schijf 
kan tot gevolg hebben dat de verkeerde wijzer wordt genomen. Deze fout zou 
kunnen leiden tot het aaneenschakelen van een bestand met een blok ergens in 
de vrije-ruimtelijst of in een ander bestand. Een gedeeltelijke oplossing hiervoor 
wordt gevormd door het gebruik van dubbel-aaneengeschakelde lijsten of het 
opbergen in elk blok van de bestandsnaam en het relatieve bloknummer; voor 
deze en dergelijke methoden is voor elk bestand nog weer meer extra administra- 
tie nodig. 
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3.4.4 Geïndiceerde toewijzing 


Aaneengeschakelde toewijzing lost de problemen op van externe fragmentatie en 
het van tevoren moeten opgeven van de grootte van het bestand, die optreden bij 
aaneengesloten toewijzing. Maar aaneengeschakelde toewijzing kan geen directe 
toegang ondersteunen, aangezien de blokken overal over de schijf verspreid lig- 
gen. Geïndiceerde toewijzing lost dit probleem op door alle wijzers bij elkaar te 
brengen op één plaats: het indexblok. 

leder bestand heeft zijn eigen indexblok, dat een rij adressen van schijfblok- 
ken is. De i-de ingang van het indexblok wijst naar het i-de blok van het bestand. 
Het adresboek bevat het adres van het indexblok (zie figuur 3.11). Om het i-de 
blok te lezen gebruiken we de wijzer in de i-de ingang van het indexblok om het 
gewenste blok te vinden en te lezen. Bij het aanmaken van het bestand worden 
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Figuur 3.11 
Geïndiceerde toewijzing van schijfruimte 
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alle wijzers in het indexblok op nul gezet. Wannneer het i-de blok voor het eerst 
geschreven wordt, wordt een blok van de vrije-ruimtelijst afgehaald en wordt zijn 
adres in de i-de ingang van het indexblok gezet. 

Geïndiceerde toewijzing ondersteunt directe toegang zonder last te hebben 
van externe fragmentatie. Met elk vrij blok, waar ook op de schijf, kan aan een 
verzoek voor meer ruimte worden voldaan. 

Geïndiceerde toewijzing lijdt wel aan ruimteverspilling. De totale hoeveel- 
heid ruimte die wijzers in beslag nemen in het indexblok is in het algemeen meer 
dan bij aaneengeschakelde toewijzing. De meeste bestanden zijn klein. Stel dat 
we een bestand hebben van slechts één of twee blokken. Met aaneengeschakelde 
toewijzing verliezen we slechts de ruimte van één wijzer per blok (één of twee 
wijzers). Met geïndiceerde toewijzing moet een geheel indexblok worden toegewe- 
zen, zelfs al hebben slechts één of twee wijzers een waarde die niet-nul is. 

Dit punt roept de vraag op hoe groot het indexblok moet zijn. Elk bestand 
moet een indexblok hebben, dus willen we dat het indexblok zo klein mogelijk 
is. Is het indexblok echter te klein, dan zal het voor een groot bestand niet genoeg 
wijzers kunnen bevatten. Een indexblok beslaat gewoonlijk één schijfblok. Daar- 
door kan het op zichzelf rechtstreeks worden gelezen en geschreven. Met het 
oog op grote bestanden kunnen verschillende indexbestanden aaneengeschakeld 
worden. Een indexblok zou bijvoorbeeld een kleine kop kunnen bevatten die de 
naam van het bestand aangeeft alsmede een groep schijfadressen, zeg de eerste 
honderd. Het volgende adres (het laatste woord in het indexblok) is de nul-wijzer 
(voor een klein bestand) of een wijzer naar een tweede indexbestand (voor een 
groot bestand). Voor een heel groot bestand zou dit tweede indexbestand kunnen 
wijzen naar een derde, enzovoort. 

Let erop dat deze vorm van het indexblok een aaneengeschakelde toe- 
wijzing voor de indexblokken gebruikt. Een variant op deze vorm gebruikt een 
afzonderlijk indexblok om naar de indexblokken te wijzen die naar het bestand 
zelf wijzen. Om toegang tot een blok te verkrijgen gebruikt het besturingssysteem 
de index van niveau 1 om de index van niveau 2 te vinden, om van daaruit het 
gewenste gegevensblok te vinden. Deze benadering zou kunnen worden voortge- 
zet tot een derde en vierde niveau, maar twee indexniveaus zijn in het algemeen 
voldoende. Als we 256 wijzers in een indexblok kunnen krijgen, geven twee index- 
niveaus de mogelijkheid van 65.536 gegevensblokken, die (als ze elk uit 1024 
bytes bestaan) een bestand mogelijk maken van 67.108.864 bytes, een grootte die 
de fysieke capaciteit van veel randapparatuur overschrijdt. 

Een alternatief wordt gevormd door de eerste, zeg vijftien, wijzers van het 
indexblok in het randapparaatadresboek te houden. Als een bestand meer dan 
vijftien blokken nodig heeft wijst een zestiende wijzer naar een lijst van index- 
blokken. Op deze manier hebben kleine bestanden geen afzonderlijk indexblok 
nodig. Het Unix-besturingssysteem maakt gebruik van een schema dat hierop 
lijkt. 


34 Toewijzingsmethoden 85 


34.5 Prestatievermogen 


De verschillende toewijzingsmethoden verschillen aanzienlijk in efficiënt geheu- 
gengebruik. Ze verschillen ook in de tijd die nodig is om toegang te krijgen tot 
een blok op schijf. Deze factor is bijzonder belangrijk voor kleine, langzame schij- 
vensystemen. 

Een moeilijkheid bij het vergelijken van de prestaties van de verschillende 
systemen schuilt in het vaststellen hoe ze zullen worden gebruikt. Voor elk soort 
toegang is bij aaneengesloten toewijzing slechts één toegang nodig om bij een 
schijfblok te komen. Aangezien we gemakkelijk het beginadres van het bestand 
in het geheugen kunnen houden, kunnen we onmiddellijk het schijfadres van het 
i-de blok (of het volgende blok) berekenen en het rechtstreeks lezen. 

Bij aaneengeschakelde toewijzing kunnen we eveneens het adres van het 
volgende blok in het geheugen houden en het rechtstreeks lezen. Deze methode 
werkt goed voor sequentiële toegang, maar voor directe toegang zouden voor het 
i-de blok i leesbewerkingen op de schijf nodig kunnen zijn. Dit probleem geeft 
al aan waarom aaneengeschakelde toewijzing niet gebruikt moet worden voor een 
toepassing die directe toegang vereist. 

Het gevolg is dat sommige systemen bestanden met directe toegang onder- 
steunen door gebruik te maken van aaneengesloten toewijzing, en die met sequen- 
tiële toegang door middel van aaneengeschakelde toewijzing. Voor deze systemen 
moet de toegangsmethode opgegeven worden bij het aanmaken van het bestand. 
Een bestand dat wordt gemaakt voor sequentiële toegang wordt aaneenge- 
schakeld en kan niet worden gebruikt voor directe toegang. Een bestand dat 
wordt gemaakt voor directe toegang is dan aaneengesloten en zal zowel directe 
toegang als sequentiële toegang ondersteunen, maar zijn maximale lengte moet 
worden opgegeven wannneer het gemaakt wordt. Let wel dat in dit geval het 
besturingssysteem geschikte gegevensstructuren en algoritmen moet hebben om 
beide toewijzingsmethoden te ondersteunen. Bestanden kunnen worden omgezet 
van het ene naar het andere type door een nieuw bestand aan te maken van 
het gewenste soort, waarin vervolgens de inhoud van het oude bestand wordt 
gekopieerd. Het oude bestand kan dan opgeheven en het nieuwe herbenoemd 
worden. 

Geïndiceerde toewijzing is complexer. Als het indexblok al in het geheugen 
staat, kan meteen toegang verkregen worden. Het in het geheugen bewaren van 
het indexblok vereist evenwel heel wat ruimte. Als deze geheugenruimte niet be- 
schikbaar is, moeten we mogelijk het indexblok eerst lezen en daarna het gewens- 
te gegevensblok. Voor een index met twee niveaus kunnen twee leesbewerkingen 
nodig zijn. Om toegang te verkrijgen tot een blok dichtbij het eind van een zeer 
groot bestand zouden we genoodzaakt zijn alle indexblokken in te lezen om de 
keten van wijzers te volgen, voordat uiteindelijk het gegevensblok gelezen kan 
worden. Het prestatievermogen van geïndiceerde toewijzing hangt dus af van de 
indexstructuur, de grootte van het bestand en de positie van het gewenste blok. 

Sommige systemen combineren aaneengesloten toewijzing met geïndiceerde 
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toewijzing, door aaneengesloten toewijzing te gebruiken voor kleine bestanden 
(niet meer dan drie of vier blokken), en automatisch over te schakelen op geïn- 
diceerde toewijzing als het bestand groot wordt. Aangezien de meeste bestanden 
klein zijn en aaneengesloten toewijzing efficiënt is voor kleine bestanden, kan het 
gemiddelde prestatievermogen heel goed zijn. 


3.5 Adresboeksystemen 


De voorgaande bespreking stelt ons in staat bestanden te maken, te lezen, te 
schrijven, opnieuw te positioneren en tenslotte op te heffen. De bestanden wor- 
den gerepresenteerd door ingangen in een randapparaatadresboek of volume- 
inhoudsopgave. In het randapparaatadresboek is de informatie, zoals de naam, 
plaats, grootte en soort, voor alle bestanden op dat randapparaat vastgelegd. 

Een randapparaatadresboek kan voldoende zijn voor een systeem met één 
gebruiker en met beperkte geheugenruimte. Naarmate echter de hoeveelheid ge- 
heugenruimte en het aantal gebruikers groter worden, wordt het steeds moeilijker 
voor de gebruikers alle bestanden te organiseren en bij te houden. We lossen 
dit probleem op door aan het bestandssysteem een adresboekstructuur voor te 
schrijven. Een adresboekstructuur geeft een mechanisme voor het organiseren 
van de vele bestanden in het bestandssysteem. Dit kan meer dan één randappa- 
raat omspannen en meerdere schijveneenheden. Aldus hoeft de gebruiker alleen 
rekening te houden met de logische structuur van het adresboek en bestanden, 
en kan hij de problemen van het toewijzen van fysieke ruimte voor bestanden 
geheel negeren. 

In feite hebben vele systemen twee afzonderlijke adresboekstructuren: het 
randapparaatadresboek en de bestandsadresboeken. Het randapparaatadresboek 
wordt opgeslagen op het fysieke randapparaat en beschrijft alle bestanden op dat 
randapparaat. Elke ingang van dit adresboek concentreert zich hoofdzakelijk op 
het beschrijven van de fysieke eigenschappen van elk bestand: waar het is, hoe 
lang het is, hoe de ruimte is toegewezen, enzovoort. De bestandsadresboeken 
vormen een logische organisatie van de bestanden op alle randapparaten. Elke 
ingang van het bestandsadresboek concentreert zich op logische eigenschappen 
van het bestand: naam, bestandssoort, eigenaar-gebruiker, informatie voor de 
boekhouding, beveiligingstoegangscodes, enzovoort. Een ingang van het be- 
standsadresboek kan eenvoudig naar de ingang van het randapparaatadresboek 
wijzen voor het geven van informatie over de fysieke eigenschappen, of kan deze 
informatie ook wel dupliceren. Onze voornaamste interesse geldt nu de structuur 
van het bestandsadresboek; randapparaatadresboeken moeten nu wel begrepen 
zijn. 

Er zijn tal van verschillende bestandsstructuren voorgesteld en in gebruik. 
Het adresboek is in wezen een symbolentabel. Het besturingssysteem neemt de 
symbolische bestandsnaam en zoekt het benoemde bestand op. We zullen hier 
enige adresboekstructuren onderzoeken. Beschouwen we een bepaalde adres- 
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boekstructuur, dan moeten we de bewerkingen die op het adresboek uitgevoerd 
moeten worden in gedachten houden. 


@ Zoeken. We moeten in staat zijn een adresboekstructuur te doorzoeken om de 
ingang voor een bepaald bestand te vinden. Aangezien bestanden symbolische 
namen hebben en gelijksoortige namen een verwantschap tussen de bestanden 
kunnen aangeven, willen we mogelijk alle bestanden vinden in de naam waar- 
van een bepaalde combinatie van tekens voorkomt. 

@ Een bestand aanmaken. Er moeten nieuwe bestanden worden gemaakt en aan 
het adresboek worden toegevoegd. 

@ Een bestand opheffen. Wanneer een bestand niet langer nodig is willen we het 
uit het adresboek verwijderen. 

@ Het adresboek uitlijsten. We moeten de bestanden in een adresboek kunnen 
uitlijsten, evenals de inhoud van de adresboekingang voor ieder bestand in de 
lijst. 

@ Een reservebestand (backup) aanmaken. Uit oogpunt van betrouwbaarheid is 
het in het algemeen een goed idee de inhoud en structuur van het bestandssys- 
teem met regelmatige tussenpozen ergens op te slaan. Dit houdt vaak in dat 
alle bestanden worden gekopieerd naar magneetband. Dit levert een reser- 
vekopie op voor het geval dat er een systeemfout optreedt of dat het bestand 
niet langer gebruikt wordt. In dit geval kan het bestand worden gekopieerd 
naar magneetband en de schijfruimte van dat bestand worden vrijgegeven om 
opnieuw te worden gebruikt door een ander bestand. 


3.5.1 Adresboek met één niveau 


De eenvoudigste adresboekstructuur is het adresboek met één niveau. Het rand- 
apparaatadresboek is een voorbeeld van een adresboek met één niveau. Alle be- 
standen zijn opgenomen in hetzelfde adresboek, wat erg gemakkelijk onder- 
steund en begrepen kan worden (zie figuur 3.12). 

Een adresboek met één niveau heeft echter aanzienlijke beperkingen wan- 
neer het aantal bestanden toeneemt of wanneer er meer dan één gebruiker is. 
Daar alle bestanden in hetzelfde adresboek staan, moeten ze unieke namen heb- 
ben. Als we twee gebruikers hebben die hun bestand met testgegevens TEST 
noemen, wordt tegen de regel van de unieke naamgeving gezondigd. (Bijvoor- 
beeld, in een programeerles noemden 23 studenten het programma voor hun 
tweede opdracht, PROG2; nog eens 11 anderen noemden dit OPG2.) Hoewel in 
het algemeen bestandsnamen zó worden uitgezocht dat ze de inhoud van het 
bestand weerspiegelen, is de naamlengte vaak zeer beperkt. (TOPS-10 van DEC 
staat slechts bestandsnamen toe van zes tekens; Unix staat veertien tekens toe.) 

Zelfs met één gebruiker wordt het, naarmate het aantal bestanden toe- 
neemt, moeilijk zich de namen van alle bestanden te herinneren, en toch moeten 
alle bestanden unieke namen hebben. (Het is niet ongewoon dat een gebruiker 
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Figuur 3.12 
Adresboek met één niveau 


honderden bestanden op een computersysteem heeft en nog eens eenzelfde aantal 
op een ander systeem.) 


3.5.2 Adresboek met twee niveaus 


Het belangrijkste nadeel van een adresboek met één niveau is de verwarring van 
bestandsnamen tussen verschillende gebruikers. De standaardoplossing is het 
maken van een afzonderlijk adresboek voor iedere gebruiker. Speciaal voor een 
groot systeem is dit gebruikersadresboek eerder een logische dan een fysieke orga- 
nisatie, daar alle bestanden fysiek nog steeds op hetzelfde randapparaat staan. 

In de adresboekstructuur met twee niveaus heeft iedere gebruiker zijn eigen 
gebruikersbestandsadresboek (GBA). Ieder gebruikersadresboek heeft een gelijk- 
soortige structuur (lineair, binair of hashed), maar vermeldt alleen de bestanden 
van één enkele gebruiker. Wanneer een gebruikersprogramma begint, of een ge- 
bruiker zich aanmeldt, wordt het hoofdbestandsadresboek (HBA) doorzocht. Het 
HBA is geïndiceerd met behulp van de gebruikersnaam of het rekeningnummer, 
en elke ingang wijst naar het gebruikersadresboek voor die gebruiker (zie figuur 
3.13). 

Wanneer gebruikers naar een bepaald bestand verwijzen, wordt alleen in 
hun eigen gebruikersadresboek gezocht. Zo kunnen verschillende gebruikers be- 
standen met dezelfde naam hebben, als de bestandsnamen binnen elk gebrui- 
kersadresboek maar uniek zijn. 

Voor het maken van een bestand voor een gebruiker zoekt het besturings- 
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Figuur 3.13 
Adresboekstructuur met twee niveaus 


systeem alleen in het gebruikersadresboek voor die gebruiker om na te gaan of 
er al een bestand met die naam bestaat. Voor het opheffen van een bestand be- 
perkt het besturingssysteem het zoeken tot het lokale gebruikersadresboek; zo 
kan het niet per ongeluk een bestand met dezelfde naam van een andere gebruiker 
opheffen. 

De gebruikersadresboeken zelf moeten, naargelang dit nodig is, worden ge- 
maakt en opgeheven. Een speciaal systeemprogramma wordt gedraaid met de 
juiste gebruikersnaam en rekening-informatie. Het programma maakt een nieuw 
gebruikersbestandsadresboek en voegt een ingang toe aan het hoofdbestands- 
adresboek. De uitvoering van dit programma zou natuurlijk aan beperkingen 
onderworpen kunnen zijn. De toewijzing van schijfruimte voor gebruikersadres- 
boeken kan plaatsvinden met gebruikmaking van de technieken besproken in 
paragraaf 3.4 voor bestanden zelf. 

Er zijn nog steeds problemen met de adresboekstructuur met twee niveaus. 
Deze structuur isoleert in feite de ene gebruiker van de andere. Dit is een voordeel 
wanneer de gebruikers volledig onafhankelijk zijn, maar een nadeel wanneer de 
gebruikers juist wensen samen te werken aan een of andere taak en toegang willen 
hebben tot de bestanden van andere gebruikers. Sommige systemen staan een- 
voudig niet toe dat lokale gebruikersbestanden toegankelijk zijn voor andere ge- 
bruikers. 

Als deze toegang wel geoorloofd is, moet de ene gebruiker de mogelijkheid 
hebben naar de naam van een bestand in het adresboek van een andere gebruiker 
te verwijzen. Om met een unieke naam naar een bepaald bestand in een adres- 
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boek met twee niveaus te verwijzen moeten we zowel de naam van de gebruiker 
als de naam van het bestand opgeven. Een adresboek met twee niveaus kan wor- 
den opgevat als een boom met hoogte 2. De wortel van de boom is het hoofdbe- 
standsadresboek. Zijn directe afstammelingen zijn de gebruikersadresboeken. De 
afstammelingen van de gebruikersadresboeken zijn de bestanden zelf. De bestan- 
den zijn de bladeren van de boom. Door de naam van een gebruiker en de naam 
van een bestand te specificeren definieert men een pad in de boom vanaf de 
wortel (het HBA) naar een blad (het gespecificeerde bestand). Aldus definiëren 
een gebruikersnaam en een bestandsnaam de padnaam. Elk bestand in het sys- 
teem heeft een unieke padnaam. Om eenduidig naar een bestand te verwijzen 
moet de gebruiker de padnaam van het gewenste bestand weten. 

Als gebruiker A bijvoorbeeld toegang wenst tot zijn eigen testbestand kan 
hij eenvoudigweg de naam TEST gebruiken. Voor het toegang verkrijgen tot het 
testbestand van gebruiker B zou hij wellicht de naam TEST[GEBRUIKERB] of 
/GEBRUIKERB/TEST moeten opgeven. Elk systeem heeft zijn eigen syntaxis 
voor het benoemen van bestanden in adresboeken buiten dat van de gebruiker 
zelf. 

Een speciaal geval in dit verband vinden we bij systeembestanden. Die pro- 
gramma’s die als onderdeel van het systeem geleverd worden (laadprogramma’s, 
assembleerprogramma’s, compileerprogramma’s, functieroutines, bibliotheken, 
enzovoort) zijn gewoonlijk gedefinieerd als bestanden. Wanneer aan het bestu- 
ringssysteem de juiste commando’s worden gegeven, worden deze bestanden ge- 
lezen door het laadprogramma en uitgevoerd. Veel commandovertolkers doen 
hun werk door simpelweg het commando te behandelen als de naam van een 
bestand dat moet worden geladen en uitgevoerd. Volgens het adresboeksysteem 
zoals dat nu is gedefinieerd zou de naam van dit bestand worden opgezocht in 
het bestandsadresboek van de gebruiker in kwestie. Eén oplossing bestaat hierin 
dat alle systeembestanden worden gekopieerd naar het adresboek van iedere ge- 
bruiker. Het kopiéren van alle systeembestanden zou een enorme verspilling van 
ruimte betekenen. (Zou het systeem 5 megabytes nodig hebben, dan zou de on- 
dersteuning voor 12 gebruikers zestig (5 x 12) magabytes alleen al voor kopieén 
van de systeembestanden vereisen.) 

De standaardoplossing is de zoekprocedure een klein beetje gecompliceer- 
der te maken. Er wordt een speciaal gebruikersadresboek gedefinieerd dat sys- 
teembestanden bevat (gebruiker 0 bijvoorbeeld). Wanneer de naam van een be- 
stand dat moet worden geladen wordt opgegeven, zoekt het besturingssysteem 
eerst in het lokale gebruikersbestandsadresboek. Wordt het bestand gevonden, 
dan wordt dit gebruikt. Wordt het niet gevonden, dan zoekt het systeem automa- 
tisch in het speciale gebruikersadresboek dat de systeembestanden bevat. De 
zoekvolgorde door de adresboeken wanneer een bestand benoemd is wordt het 
zoekpad genoemd. 
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3.5.3 Adresboeken met boomstructuur 


Wordt een adresboek met twee niveaus eenmaal gezien als een boom met twee 
niveaus, dan is het natuurlijke generaliseringsproces de adresboekstructuur uit te 
breiden tot een willekeurige boom (zie figuur 3.14). Dit geeft de gebruikers de 
gelegenheid hun eigen subadresboeken op te zetten en hun bestanden dienover- 
eenkomstig te organiseren. Het Unix-bestandssysteem bijvoorbeeld heeft een 
boomstructuur. De boom heeft een worteladresboek. Ieder bestand heeft een 
unieke padnaam. Een padnaam vertelt hoe het pad loopt van de wortel, door alle 
subadresboeken, naar een aangegeven bestand. 

Een adresboek (of subadresboek) bevat een groep bestanden en/of sub- 
adresboeken. Alle adresboeken hebben hetzelfde interne formaat. Een bit in elke 
adresboekingang definieert de ingang als een bestand (0) of een subadresboek 
(1). Speciale systeemaanroepen worden gebruikt om adresboeken te maken en 
op te heffen. 

Bij normaal gebruik heeft iedere gebruiker een lopend adresboek. Het lopen- 
de adresboek moet de meeste van de bestanden bevatten die op dat moment voor 
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Figuur 3.14 
Adresboek met boomstructuur 
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de gebruiker van belang zijn. Wanneer naar een bestand wordt verwezen, wordt 
het lopende adresboek doorzocht. Is een bestand nodig dat niet in het lopende 
adresboek voorkomt, dan moet de gebruiker óf een padnaam opgeven óf het 
lopende adresboek veranderen. Een systeemaanroep zal de naam van een adres- 
boek als een parameter aannemen en deze gebruiken om het lopende adresboek 
opnieuw te definiëren. Zo kunnen gebruikers hun lopend adresboek veranderen 
wanneer dat maar gewenst is. Wanneer een gebruikersjob gestart wordt, of een 
gebruiker zich aanmeldt, zoekt het besturingssysteem in het boekhoudbestand 
een ingang op voor deze gebruiker (voor het bijhouden van de boekhouding). 
Ook wordt in het boekhoudbestand een wijzer naar (of de naam van) het aanvan- 
kelijke adresboek van de gebruiker gezet. Er wordt een lokale variabele voor deze 
gebruiker (of voor dit proces) gedefinieerd die het lopende adresboek van de 
gebruiker aangeeft. 

Er kunnen twee soorten padnamen zijn: volledige padnamen of relatieve 
padnamen. Een volledige padnaam begint bij de wortel en volgt een pad helemaal 
naar het aangegeven bestand, waarbij de namen van de adresboeken op het pad 
worden gegeven. Een relatieve padnaam definieert een pad vanaf het lopende 
adresboek. Als bijvoorbeeld in het bestandsysteem met boomstructuur van figuur 
3.14 het lopende adresboek wortel/spel/post is, dan verwijst de relatieve padnaam 
afdr/eerste naar hetzelfde bestand als de volledige padnaam wortel/spel/post/ 
afdr/eerste. 

Doordat gebruikers hun eigen subadresboeken mogen definiéren, krijgen 
ze de gelegenheid in hun bestanden structuur aan te brengen. Deze structuur zou 
tot gevolg kunnen hebben dat afzonderlijke adresboeken worden geassocieerd 
met verschillende onderwerpen (er werd bijvoorbeeld een subadresboek opgezet 
voor het opslaan van de (Engelse) tekst van dit boek) of met verschillende vormen 
van informatie (het adresboek programs zou bijvoorbeeld bronprogramma’s kun- 
nen bevatten, terwijl in het adresboek bin dan alle binaire informatie zou kunnen 
zijn opgeslagen). 

Een interessante beleidskwestie is de vraag hoe bij een boomstructuur het 
opheffen van een adresboek in zijn werk moet gaan. Als een adresboek leeg is, 
kan de ingang in het hoger gelegen adresboek eenvoudig opgeheven worden. Stel 
echter dat het adresboek dat opgeheven moet worden niet leeg is, maar diverse 
bestanden, of mogelijk subadresboeken, bevat. Dan kan men op één van de twee 
volgende manieren te werk gaan. Sommige systemen zullen geen adresboek op- 
heffen tenzij het leeg is. Om dus een adresboek op te heffen moet iemand eerst 
alle bestanden in dat adresboek opheffen. Als er subadresboeken zijn moet deze 
procedure recursief daarop worden toegepast, zodat deze ook opgeheven kunnen 
worden. Deze manier kan een aanzienlijke hoeveelheid werk tot gevolg hebben. 

Een tweede manier is gewoon te veronderstellen dat, wanneer een verzoek 
wordt gedaan om een adresboek op te heffen, al zijn bestanden en subadresboe- 
ken ook opgeheven moeten worden. Let erop dat beide manieren vrij gemakkelijk 
zijn te implementeren; de implementatiekeuze is een beleidsbeslissing. Men heeft 
elk van beide implementaties in systemen toegepast. 
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Tot bestanden van andere gebruikers kan gemakkelijk toegang worden ver- 
kregen. Bijvoorbeeld, gebruiker B kan toegang krijgen tot de bestanden van ge- 
bruiker A door hun padnamen te specificeren. Gebruiker B kan óf een volledige 
óf een relatieve padnaam opgeven. Ook is het mogelijk dat het lopende adresboek 
van gebruiker B wordt veranderd, zodat dit het adresboek van gebruiker A wordt, 
en gebruiker B de bestanden direct kan adresseren door middel van hun be- 
standsnamen. Sommige systemen geven ook de mogelijkheid dat een gebruiker 
een eigen zoekpad definiëert. In dit geval zou gebruiker B een zoekpad kunnen 
definiëren als: (1) zijn lokaal adresboek, (2) het bestandsadresboek van het sys- 
teem, en (3) het adresboek van gebruiker A, in die volgorde. Zolang er geen con- 
flict optreedt tussen de naam van een bestand van gebruiker A en de naam van 
een lokaal bestand of een systeembestand, kan naar het bestand van gebruiker A 
eenvoudig met de bestandsnaam worden verwezen. 


3.5.4 Adresboeken met acyclische-graafstructuur 


Neem twee programmeurs die werken aan een gemeenschappelijk project. De 
bestanden die te maken hebben met dat project kunnen worden opgeslagen in 
een subadresboek, zodat ze gescheiden zijn van de andere projecten en bestanden 
van de twee programmeurs. Maar aangezien beide programmeurs in gelijke mate 
verantwoordelijk zijn voor het project, willen beiden het subadresboek in hun 
eigen adresboek hebben. Het gemeenschappelijke adresboek moet gemeenschap- 
pelijk gebruikt worden. Een gemeenschappelijk gebruikt adresboek of bestand zal 
in het bestandsysteem op twee (of meer) plaatsen tegelijk bestaan. Let erop dat 
een gemeenschappelijk gebruikt bestand (of adresboek) niet hetzelfde is als twee 
kopieën van het bestand (adresboek). Met twee kopieën kan elke programmeur 
zijn eigen kopie bekijken in plaats van het origineel, maar als één programmeur 
het bestand verandert zullen de veranderingen niet optreden in de kopie van de 
ander. In geval van een gemeenschappelijk gebruikt bestand is er slechts één 
eigenlijk bestand en dus zullen veranderingen aangebracht door één persoon on- 
middellijk zichtbaar zijn voor de ander. Dit is speciaal belangrijk voor subadres- 
boeken; een nieuw bestand dat door de ene persoon wordt gemaakt zal onmiddel- 
lijk voorķomen in alle subadresboeken. 

Een boomstructuur verbiedt het gemeenschappelijk gebruik van bestanden 
en subadresboeken. Een acyclische-graafstructuur staat subadresboeken met ge- 
meenschappelijk gebruik van subadresboeken en bestanden toe (zie figuur 3.15). 
Hetzelfde bestand of subadresboek kan in twee verschillende adresboeken voor- 
komen. Een acyclische graaf (dat is een graaf zonder cycli ofwel lussen) is een 
natuurlijke generalisatie van het geval van een adresboek met boomstructuur. 

In een situatie waarin verschillende mensen als team samenwerken kunnen 
alle gemeenschappelijk gebruikte bestanden samengebracht worden in één adres- 
boek. Elk van de gebruikersbestandsadresboeken van al de teamleden zou dan 
dit adresboek van gemeenschappelijk gebruikte bestanden als een subadresboek 
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Figuur 3.15 
Adresboek met acyclische-graafstructuur 


bevatten. Zelfs wanneer er slechts sprake is van één gebruiker, kan de gewenste 
bestandsorganisatie vereisen dat sommige bestanden in een aantal verschillende 
subadresboeken worden geplaatst. Bijvoorbeeld, een programma dat voor een 
bepaald project geschreven is moet zowel in het adresboek van alle programma’s 
voorkomen als in het adresboek voor dat project. 

Gemeenschappelijk gebruikte bestanden en subadresboeken kunnen op 
verschillende manieren worden geïmplementeerd. Een gebruikelijke manier is het 
aanbrengen van een nieuwe ingang in het adresboek met de naam link. Een link 
of schakel is in feite een wijzer naar een ander bestand of subadresboek. Zo’n 
schakel kan bijvoorbeeld worden geïmplementeerd als een volledige padnaam 
(een symbolische schakel). Wanneer naar een bestand wordt verwezen, zoeken we 
in het adresboek. De ingang in het adresboek is gemarkeerd als een schakel en 
de naam van het echte bestand (of adresboek) staat aangegeven. De schakel 
wordt gevolgd door gebruik te maken van de padnaam om de plaats te bepalen 
van het echte bestand. Schakels kunnen gemakkelijk worden herkend aan hun 
formaat in de ingang van het adresboek; zij worden indirecte wijzers genoemd. 

De andere manier voor het implementeren van gemeenschappelijk gebruik- 
te bestanden is eenvoudig alle desbetreffende informatie te dupliceren in de beide 
adresboeken die bij het gemeenschappelijk gebruik betrokken zijn. Op deze wijze 
zijn beide ingangen volkomen aan elkaar gelijk. Een schakel is duidelijk verschil- 
lend van de oorspronkelijke adresboekingang, dus de twee zijn niet gelijk. Gedu- 
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pliceerde adresboekingangen zorgen er echter voor dat het origineel en de kopie 
niet van elkaar zijn te onderscheiden. Een belangrijk probleem hierbij is ervoor 
te zorgen dat de consistentie behouden blijft indien het bestand wordt gewijzigd. 

Een acyclische-graafstructuur voor adresboeken is flexibeler, maar ook 
complexer, dan een eenvoudige boomstructuur. Diverse problemem moeten met 
zorg worden bekeken. Let erop dat een bestand nu meer dan één volledige pad- 
naam kan hebben. Dientengevolge kunnen verschillende bestandsnamen betrek- 
king hebben op eenzelfde bestand. Dit komt overeen met het probleem van de 
alias voor programmeertalen. Als we het gehele systeem trachten te doorlopen 
(om een bestand te vinden, statistieken te verzamelen over alle bestanden, of 
bestanden te kopiëren naar een reservegeheugen), wordt dit probleem belangrijk, 
omdat we gemeenschappelijke substructuren niet meer dan één keer willen door- 
lopen. 

Een ander probleem heeft te maken met het opheffen van een bestand. 
Wanneer kan de ruimte die was toegewezen aan een gemeenschappelijk gebruikt 
bestand worden vrijgegeven en opnieuw worden gebruikt? Een mogelijkheid is 
het bestand te verwijderen wanneer iemand het opheft, maar deze handeling kan 
tot gevolg hebben dat er wijzers in de lucht blijven hangen die wijzen naar het 
nu niet meer bestaande bestand. Erger nog, als de overblijvende bestandswijzers 
werkelijke schijfadressen bevatten en de ruimte daarna opnieuw wordt gebruikt 
voor andere bestanden, dan kunnen deze in de lucht hangende wijzers wel mid- 
denin andere bestanden wijzen. 

In een systeem waarin gemeenschappelijk gebruik is geïmplementeerd door 
middel van symbolische schakels, is deze situatie wat gemakkelijker te hanteren. 
Het opheffen van een schakel hoeft geen invloed te hebben op het oorspronkelij- 
ke bestand: alleen de schakel wordt verwijderd. Als de bestandsingang zelf wordt 
opgeheven wordt de ruimte voor het bestand vrijgegeven, waarbij de schakels 
blijven hangen. We kunnen deze schakels opsporen en deze ook verwijderen, 
maar dit zoeken kan heel kostbaar zijn, tenzij er voor ieder bestand een lijst wordt 
bijgehouden van de bijbehorende schakels. Anders kunnen we ook de schakels 
zo laten totdat er een poging wordt gedaan ze te gebruiken. Op dat moment 
kunnen we vaststellen dat het bestand met de door de schakel aangegeven naam 
niet bestaat en dat we er niet in slagen de schakelnaam thuis te brengen; de 
toegangspoging wordt dan als iedere andere illegale bestandsnaam behandeld. 
(In dit geval moet de systeemontwerper zorgvuldig nagaan wat hij moet doen 
wanneer er een bestand wordt opgeheven en een ander bestand met dezelfde 
naam wordt gemaakt, voordat er een symbolische schakel naar het oorspronkelij- 
ke bestand wordt gebruikt.) 

Een andere aanpak met betrekking tot opheffing van een bestand is het 
instandhouden van het bestand tot alle verwijzingen ernaar zijn opgeheven. Voor 
het implementeren van deze aanpak moeten we een of ander mechanisme hebben 
om vast te stellen dat de laatste verwijzing naar dit bestand opgeheven is. We 
zouden een lijst kunnen bijhouden van alle verwijzingen naar het bestand (adres- 
boekingangen of symbolische schakels). Wanneer een schakel of een kopie van 


9% Hoofdstuk 3 Bestandssystemen 


de adresboekingang wordt gemaakt, wordt een nieuw element toegevoegd aan de 
lijst van bestandsverwijzingen. Wanneer een schakel of adresboekingang wordt 
opgeheven, verwijderen we het bijbehorende element van de lijst. Het bestand 
wordt opgeheven wanneer zijn lijst van bestandsverwijzingen leeg is. 

De moeilijkheid met deze aanpak is de variabele en mogelijk grote lengte 
van de lijst met bestandsverwijzingen. We hóeven echter niet de hele lijst bij te 
houden, alleen het aantal referenties. Een nieuwe schakel of adresboekingang 
hoogt het referentieaantal op, het opheffen van een schakel of adresboekingang 
verlaagt dit. Wanneer het referentieaantal nul is kan het bestand worden opge- 
heven; er zijn geen verwijzingen naar het bestand meer over. 


3.5.5 Adresboeken met algemene-graafstructuur 


Een ernstig probleem bij het gebruik maken van een acyclische-graafstructuur is: 
hoe weten we zeker dat er geen lussen zijn? Als we beginnen met een adresboek 
met twee niveaus en gebruikers de mogelijkheid geven subadresboeken te maken, 
ontstaat er een adresboek met boomstructuur. Het is tamelijk gemakkelijk in te 
zien dat door het gewoonweg toevoegen van nieuwe bestanden en subadresboe- 
ken aan een bestaand adresboek met boomstructuur de boomstructuur behouden 
blijft. Wanneer we evenwel schakels aan een adresboek met boomstructuur toe- 
voegen, wordt de boomstructuur vernietigd, waardoor een algemene-graafstruc- 
tuur ontstaat (zie figuur 3.16). 


Figuur 3.16 
Adresboek met algemene-graafstructuur 


3.6 Bestandsbeveiliging 


Het belangrijkste voordeel van een acyclische graaf is dat de algoritmen 
voor het doorlopen ervan en voor het vaststellen dat er geen verwijzingen naar 
een bestand meer bestaan, betrekkelijk eenvoudig zijn. We willen vermijden dat 
we gemeenschappelijke secties van een acyclische graaf tweemaal doorlopen, 
voornamelijk uit oogpunt van het prestatievermogen. Als we net bij het zoeken 
naar een bepaald bestand een groot gemeenschappelijk adresboek doorzocht heb- 
ben, willen we vermijden dat we dat subadresboek nog eens gaan doorzoeken; 
dat zou tijdverspilling zijn. Als lussen in het adresboek zijn toegestaan, willen we 
evenzo vermijden dat we een onderdeel tweemaal doorzoeken, uit oogpunt van 
zowel correctheid als prestatievermogen. Een slecht ontworpen algoritme zou tot 
gevolg kunnen hebben dat we in een oneindige lus blijven zoeken zonder dat we 
daar ooit uitkomen. 

Een soortgelijk probleem treedt op wanneer we trachten te bepalen wan- 
neer een bestand kan worden opgeheven. Evenals bij adresboeken met een acycl- 
ische-graafstructuur betekent een referentieaantal nul dat er geen verwijzingen 
naar het bestand of adresboek meer zijn, zodat dit kan worden opgeheven. Het 
is echter ook mogelijk, wanneer er lussen bestaan, dat het referentieaantal niet- 
nul is, zelfs wanneer het niet meer mogelijk is naar een adresboek of bestand te 
verwijzen. Deze afwijking is het gevolg van de mogelijkheid van zelf-referentie 
(een lus) in de adresboekstructuur. In dit geval is het in het algemeen noodzake- 
lijk gebruik te maken van sanering om te bepalen wanneer de laatste verwijzing 
werd opgeheven en de schijfruimte opnieuw kan worden toegewezen. Sanering 
houdt in dat het bestandssysteem doorlopen wordt, waarbij alles waartoe toegang 
kan worden verkregen wordt gemerkt. Dan wordt in een tweede gang alles wat 
niet gemerkt is verzameld en op een vrije-ruimtelijst gezet. (Een soortgelijke 
merk-procedure kan worden gebruikt om er zeker van te zijn dat een doorgang of 
zoektocht alles in het bestandssysteem eenmaal en slechts eenmaal zal aandoen.) 
Sanering voor een systeem op schijf is evenwel uiterst tijdrovend en wordt zelden 
toegepast. 

Sanering is alleen nodig vanwege mogelijke lussen in de graaf. Met een 
acyclische-graafstructuur is dus veel gemakkelijker te werken. De moeilijkheid is 
dat we moeten zien te vermijden dat, bij het toevoegen van nieuwe schakels aan 
de structuur, lussen ontstaan. Hoe weten we wanneer een nieuwe schakel een lus 
sluit? Er zijn algoritmen om lussen in grafen te ontdekken; ze zijn echter, met 
name voor een graaf op schijvengeheugen, duur in verwerking. 


3.6 Bestandsbeveiliging 


Bij het bewaren van informatie in een computersysteem is het een punt van grote 
zorg dat deze informatie wordt beschermd tegen fysieke beschadiging (betrouw- 
baarheid) en tegen onrechtmatige toegang tot die informatie (beveiliging). 
Betrouwbaarheid wordt in het algemeen gewaarborgd door het maken van 
duplicaat-kopieën van bestanden. Veel besturingssystemen maken regelmatig 


98 Hoofdstuk 3 Bestandssystemen 


kopieën van schijfbestanden op magneetband (eens per dag of per week of per 
maand) om nog een kopie te hebben voor het geval dat een bestandssysteem per 
ongeluk wordt vernietigd. Bestandssystemen kunnen worden beschadigd door 
problemen in de apparatuur, zoals fouten bij lezen of schrijven, pieken in of het 
wegvallen van de elektriciteitsvoorziening, het stukgaan van de lees/schrijfkop- 
pen, vuil, temperatuur en vandalisme. Ook door fouten in de programmatuur van 
het bestandssysteem kan de inhoud ervan verloren gaan. 

Beveiliging kan op vele manieren worden verzekerd. Voor een klein systeem 
met één gebruiker zou beveiliging kunnen worden gegeven door het fysiek verwij- 
deren van de diskettes en deze op te bergen in een bureaulade of opbergkast die 
dan op slot gaat. In een systeem met meerdere gebruikers zijn echter andere 
mechanismen nodig. 

De noodzaak voor het beveiligen van bestanden is een rechtstreeks gevolg 
van de mogelijkheid toegang te verkrijgen tot bestanden. Op systemen die niet 
toestaan dat gebruikers toegang hebben tot de bestanden van andere gebruikers 
is beveiliging niet nodig. Het ene uiterste zou dus zijn volledige beveiliging te 
verzekeren door deze toegang te beletten. Het andere uiterste is het verlenen van 
vrije toegang zonder beveiliging. Beide methoden zijn te extreem voor algemeen 
gebruik. Wat we nodig hebben is gereguleerde toegang. 

Gereguleerde toegang wordt geleverd door beveiligingsmechanismen die 
beperkingen opleggen aan de soorten toegang tot bestanden. Toegang wordt ver- 
leend of geweigerd afhankelijk van diverse factoren, waarvan er één het soort 
toegang is waarom wordt verzocht. Diverse soorten bewerkingen kunnen worden 
gereguleerd: 


@ Lees. Lees van het bestand. 

e Schrijf. Schrijf of schrijf opnieuw naar het bestand. 

@ Voer uit. Laad het bestand in het geheugen en voer dit uit. 

@ Voeg toe. Schrijf nieuwe informatie bij aan het einde van het bestand. 

@ Hef op. Hef het bestand op en geef zijn ruimte vrij voor mogelijk hergebruik. 


Andere bewerkingen, zoals het herbenoemen van het bestand, of het kopië- 
ren of opmaken (edit) ervan, kunnen ook worden gereguleerd. In veel systemen 
kunnen deze hogere functies (zoals het kopiëren) geïmplementeerd zijn door een 
systeemprogramma dat systeemaanroepen op lager niveau doet. Beveiliging 
wordt alleen gegeven op het lagere niveau. Het kopiëren van een bestand kan 
bijvoorbeeld geïmplementeerd zijn met behulp van een reeks leesverzoeken. In 
dit geval kan een gebruiker met lees-toegang ook het bestand laten kopiëren, 
afdrukken, enzovoort. 

De adresboek-bewerkingen die moeten worden beveiligd zijn enigszins an- 
ders. We willen zeggenschap hebben over het maken en opheffen van bestanden 
in een adresboek. Bovendien zullen we er waarschijnlijk zeggenschap over willen 
hebben of een gebruiker het bestaan van een bestand kan vaststellen aan de hand 
van het adresboek. Soms kan kennis van het bestaan en de naam van een bestand 
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op zichzelf belangrijk zijn. Dus moet het uitlijsten van de inhoud van een adres- 
boek een beschermde bewerking zijn. 

Er zijn veel beveiligingsmechanismen voorgesteld. Zoals altijd heeft elk zijn 
voor en tegen en moet elk mechanisme worden gekozen omdat het geschikt is 
voor het gebruik waarvoor het bedoeld is. Een klein computersysteem dat alleen 
gebruikt wordt door een paar leden van een onderzoeksteam heeft niet dezelfde 
soorten beveiliging nodig als de computer van een groot bedrijf die gebruikt 
wordt voor onderzoek, boekhouding en personeelsadministratie. 


3.6.1 Naamgeving 


De beveilingsschema’s van diverse systemen hangen af van het feit dat gebruikers 
geen toegang kunnen krijgen tot een bestand dat zij niet kunnen benoemen. Als 
gebruikers een bestand niet kunnen benoemen, kunnen zij er geen bewerkingen 
op uitvoeren. Dit schema gaat uit van de veronderstelling dat er geen mechanisme 
bestaat voor het verkrijgen van de namen van gebruikersbestanden en dat de 
namen niet zo gemakkelijk kunnen worden geraden. Daar bestandsnamen in het 
algemeen worden gekozen als een geheugensteuntje, kunnen ze vaak wel gemak- 
kelijk worden geraden. 


3.6.2 Wachtwoorden 


Een andere manier is dat we aan elk bestand een wachtwoord verbinden. Net 
zoals toegang tot de computer zelf dikwijls wordt gereguleerd met behulp van 
een wachtwoord, kan toegang tot elk bestand ook worden gereguleerd met een 
wachtwoord. Als de wachtwoorden maar willekeurig worden gekozen en vaak 
worden veranderd, kan deze manier heel effectief zijn in het beperken van de 
toegang tot een bestand tot alleen diegenen die het wachtwoord weten. 

Gewoonlijk is echter slechts één wachtwoord verbonden aan een bestand. 
Zo is het een alles-of-niets beveiliging. Voor verder gaande beveiliging hebben 
we meer dan één wachtwoord nodig. 


3.6.3 Toegangsregulatie 


Weer een andere aanpak maakt toegang afhankelijk van de identiteit van de ge- 
bruiker. Diverse gebruikers kunnen verschillende soorten toegang tot een bestand 
of adresboek nodig hebben. Met elk bestand en adresboek kan een toegangslijst 
worden verbonden, waarop de gebruikersnaam en de soorten toegang die elke 
gebruiker zijn toegestaan zijn vermeld. Wanneer een gebruiker om een bepaald 
bestand verzoekt, controleert het besturingssysteem de toegangslijst van het be- 
stand. Als die gebruiker op de lijst voor de gevraagde toegang staat vermeld, 
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wordt de toegang verleend. Anders is er sprake van een beveiligingsovertreding 
en wordt de job van de gebruiker beëindigd. 

Een gecomprimeerde versie van deze aanpak tot bestandsbeveiliging wordt 
in vele systemen gebruikt. Het voornaamste probleem met toegangslijsten kan 
hun lengte zijn. Als we iedereen willen toestaan een bestand te lezen, moeten we 
alle gebruikers met lees-toegang op de lijst zetten. Om de lengte van de lijst te 
comprimeren herkennen vele systemen drie categorieën van gebruikers: eigenaar, 
groep en ieder ander. Elk bestand heeft een eigenaar: de gebruiker die het bestand 
heeft gemaakt. Bovendien kan de eigenaar behoren tot een groep van gebruikers 
die het bestand gemeenschappelijk gebruiken en gelijke toegang nodig hebben. 
De leden van een team van programmeurs, of de leerlingen van een klas, of de 
employés binnen een afdeling, kunnen bijvoorbeeld een groep vormen. Tenslotte 
zijn er al de anderen. 

Met deze indeling zijn er slechts drie velden nodig om beveiliging te definië- 
ren. Elk veld is dikwijls een verzameling bits die de toegang die met elke bit ver- 
bonden is óf toestaan óf beletten. Het Unix-systeem bijvoorbeeld definieert drie 
velden van elk drie bits: rwx, waarin r de lees-toegang (read), w de schrijf-toegang 
(write), en x de uitvoering (execution) bestuurt. Er wordt een afzonderlijk veld 
bijgehouden voor de eigenaar van het bestand, voor de groep waartoe de eigenaar 
behoort, en voor alle andere gebruikers. In deze opzet zijn negen bits per bestand 
nodig om de beveiligingsinformatie vast te leggen. 

Beveiliging kan óf met het bestand zelf óf met het pad dat tot het bestand 
leidt verbonden zijn. De meest gebruikte methode geeft beveiliging voor het pad. 
Dus als een padnaam naar een bestand in een adresboek verwijst, moet de gebrui- 
ker toegang hebben tot zowel het adresboek als het bestand. In systemen waarin 
bestanden tal van padnamen kunnen hebben (zoals acyclische of algemene-graaf- 
structuren), kan een gebruiker op verschillende manieren toegangsrecht hebben, 
afhankelijk van de gebruikte padnaam. 


3.7 Implementatiekwesties 


Een bestandssysteem levert twee heel verschillende ontwerpproblemen op. Het 
eerste probleem is de definitie van hoe het bestandssysteem er voor de gebruiker 
uit moet gaan zien. Hieronder vallen de definitie van een bestand en zijn ge- 
gevenskenmerken, de bewerkingen die op een bestand mogen plaatsvinden en de 
adresboekstructuur. Daarna moeten algoritmen en gegevensstructuren worden 
gemaakt om de relatie te leggen tussen het logische bestandssysteem en de fysieke 
randapparatuur die ter beschikking staat voor gebruik door het bestandssysteem. 

Het bestandssysteem zelf is in het algemeen opgebouwd uit verschillende 
niveaus, zoals aangegeven in figuur 3.17. Dit is een voorbeeld van een gelaagd 
ontwerp. Elk niveau in het ontwerp gebruikt de voorzieningen van lagere niveaus 
om weer nieuwe voorzieningen te geven voor gebruik door hogere niveaus. 

Het laagste niveau, de besturing van de I/O, bestaat uit stuurprogramma's 
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Toepassingsprogramma’s 


Logisch bestandssysteem 
Bestandsorganisatiemodule 
Basisbestandssysteem 


Besturing van invoer/uitvoer 


| 


Randapparatuur 


Figuur 3.17 
Bestandssysteem met verschillende lagen 


voor de randapparatuur en onderbrekingsfunctieprogramma’s om informatie tus- 
sen het geheugen en het schijvensysteem over te brengen. Het basisbestandssys- 
teem gebruikt dit om bepaalde blokken van en naar schijf te lezen en te schrijven. 
Elk schijfblok wordt geïdentificeerd door zijn numerieke schijfadres (bijvoor- 
beeld schijfeenheid 1, cilinder 73, oppervlak 2, sector 10). 

De bestandsorganisatiemodule kent zowel bestanden als schijfblokken. 
Doordat deze module het type van de bestandstoewijzing die gebruikt is en ook 
de plaats van het bestand kent, kan hij de adressen genereren van de blokken die 
het basisbestandssysteem moet lezen. Tenslotte maakt het logisch bestandssys- 
teem gebruik van de adresboekstructuur om de bestandsorganisatiemodule de 
waarden die hij nodig heeft vanuit een symbolische bestandsnaam te leveren. 

Voor het maken van een nieuw bestand roept een toepassingsprogramma 
het logisch bestandssysteem aan. Het logisch bestandssysteem kent het formaat 
van de adresboekstructuren. Het leest het juiste adresboek in het geheugen in, 
werkt het bij door middel van de nieuwe ingang en schrijft het terug naar de 
schijf. De adresboeken kunnen op precies dezelfde manier als bestanden behan- 
deld worden: bestanden met een type-veld om aan te geven dat zij adresboeken 
zijn. Zo kan het logisch bestandssysteem de bestandsorganisatiemodule aanroe- 
pen om de adresboek-I/O om te zetten in schijfbloknummers, die dan worden 
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doorgegeven aan het basisbestandssysteem en het systeem voor de besturing van 
de in- en uitvoer. 

Is het adresboek eenmaal bijgewerkt, dan kan het logisch bestandssysteem 
dit gebruiken voor de I/O. Wanneer een bestand geopend wordt, wordt in de 
adresboekstructuur gezocht naar de ingang van het gewenste bestand. Het is mo- 
gelijk voor elke 1/O-bewerking in de adresboekstructuur te zoeken, maar dat zou 
inefficiënt zijn. Om het zoeken te bespoedigen wordt in het algemeen een tabel 
van geopende bestanden door het besturingssysteem in het geheugen bewaard. 
De eerste verwijzing naar een bestand (gewoonlijk een open) zorgt ervoor dat de 
adresboekstructuur wordt doorzocht en de adresboekingang voor dit bestand 
naar de tabel van de geopende bestanden wordt gekopieerd. De plaats in deze 
tabel wordt aan het gebruikersprogramma teruggegeven en alle verdere verwijzin- 
gen gaan met behulp van deze index (bestandsbeschrijver) in plaats van met een 
symbolische naam. Alle veranderingen in de adresboekingang hebben dan be- 
trekking op de kopie in de tabel van de geopende bestanden. Wanneer het be- 
stand gesloten wordt, wordt de bijgewerkte ingang teruggekopieerd naar de 
adresboekstructuur op schijf. 

Omdat deze aanpak veel sneller is dan het steeds weer verwijzen naar de 
kopie op schijf van de adresboekingang, kan deze problemen opleveren. Als er 
een fout optreedt in het besturingssysteem, gaat in het algemeen de tabel van de 
geopende bestanden verloren en daarmee tevens iedere mogelijke verandering in 
de adresboeken van geopende bestanden. Dit kan het bestandssysteem achterla- 
ten in een toestand van tegenstrijdigheid, waar de echte toestand van sommige 
bestanden niet overeenkomt met de toestand zoals die beschreven staat in de 
adresboekstructuur. 

Een ander aspect van bestandsgebruik dat zorgvuldig moet worden gedefi- 
nieerd is de toegangsregulatie (beveiliging). Iedere toegangspoging tot een be- 
stand moet op correctheid worden gecontroleerd. Men heeft systemen ontworpen 
die alleen op bestandsbeveiliging controleren wanneer het bestand geopend 
wordt. Afzonderlijke systeemaanroepen worden daarbij gebruikt voor open voor 
lezen en open voor schrijven. Hoewel het besturingssysteem zeker op dit moment 
op bestandsbeveiliging kan controleren, moet het doorgaan met controleren of 
er naar een bestand dat open voor lezen is nooit geschreven wordt. Dus elke 
toegang tot een bestand moet op zijn geldigheid worden gecontroleerd. 


3.8 Samenvatting 


Een bestand is een abstract gegevenstype, gedefinieerd en geïmplementeerd 
door het besturingssysteem. Een bestand is een reeks logische records. Een lo- 
gisch record kan een byte zijn, een regel (met vaste of variabele lengte), of een 
complexer gegeven. Het besturingssysteem kan specifieke ondersteuning verlenen 
voor verschillende soorten records, of kan dit aan het toepassingsprogramma 
overlaten. 


3.8 Samenvatting 


Het voornaamste probleem voor het besturingssysteem is het leggen van 
een relatie tussen het begrip logisch bestand en de fysieke opslagapparatuur, zo- 
als magneetband of schijf. Daar de fysieke recordgrootte niet gelijk hoeft te zijn 
aan de logische recordgrootte, kan het noodzakelijk zijn de logische records tot 
blokken fysieke records samen te voegen. Deze taak kan ook weer ondersteund 
worden door het besturingssysteem, of worden overgelaten aan het toepassings- 
programma. 

Bestandssystemen op magneetband zijn heel beperkt; de meeste bestands- 
systemen werken met schijvengeheugens. Magneetbanden worden gewoonlijk ge- 
bruikt voor het transport van gegevens tussen machines, of voor reserve- of ar- 
chiefgeheugen. 

In een schijvensysteem kunnen bestanden óf sequentieel óf direct-toeganke- 
lijk zijn. Aan bestanden kan op drie manieren ruimte op de schijf worden toe- 
gewezen: aaneengesloten, aaneengeschakeld, of geïndiceerd. Aaneengesloten toe- 
wijzing kan mank gaan aan externe fragmentatie. Direct-toegankelijke bestanden 
kunnen niet worden ondersteund met aaneengeschakelde toewijzing. Geïndiceer- 
de toewijzing kan een aanzienlijke hoeveelheid extra ruimte vereisen voor het 
indexblok. 

Op elk randapparaat in een bestandssysteem wordt een volume-inhoudsop- 
gave of adresboek bijgehouden, waarin de plaats van de bestanden op het randap- 
paraat staan vermeld. Bovendien is het nuttig adresboeken op te zetten om de 
bestanden te organiseren. Een adresboek met één niveau geeft benoemingspro- 
blemen, daar elk bestand een unieke naam moet hebben. Een adresboek met twee 
niveaus lost dit probleem op door het samenstellen van een afzonderlijk adres- 
boek voor elke gebruiker. Gebruikers hebben ieder hun eigen adresboek waarin 
hun eigen bestanden staan vermeld. 

De natuurlijke generalisatie van een adresboek met twee niveaus is een 
adresboek met boomstructuur. Dit geeft de gebruikers de gelegenheid subadres- 
boeken te maken voor het organiseren van hun bestanden. Acyclische-graafstruc- 
turen geven de mogelijkheid tot gezamenlijk gebruik van subadresboeken en be- 
standen, maar maken het zoeken en opheffen gecompliceerder. Een algemene- 
graafstructuur geeft volledige flexibiliteit in het gezamenlijk gebruik van bestan- 
den en adresboeken, maar vereist soms sanering om ongebruikte schijfruimte 
terug te krijgen. 

Aangezien in de meeste computersystemen bestanden het voornaamste me- 
chanisme voor de opslag van informatie vormen, is bestandsbeveiliging nodig. 
Toegang tot bestanden kan afzonderlijk worden gereguleerd voor elk soort toe- 
gang: lezen, schrijven, uitvoeren, toevoegen, uitlijsten van het adresboek, enzo- 
voort. Bestandsbeveiliging kan worden gegeven door middel van wachtwoorden, 
toegangslijsten, of speciale ad hoc technieken. 

Bestandssystemen worden dikwijls geïmplementeerd in een gelaagde of mo- 
dulaire structuur. De lagere niveaus behandelen de fysieke eigenschappen van 
opslagapparatuur. De hogere niveaus werken met symbolische bestandsnamen 
en logische eigenschappen van bestanden. De tussenliggende niveaus vertalen de 
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logische bestandskenmerken naar de fysieke eigenschappen van de randappara- 


tuur. 


Opgaven 


3.1 


3.2 


3.3 


3.4 


3.5 


3.6 


3.7 


Neem een bestandssysteem waarin een bestand kan worden opgeheven 
en zijn schijfruimte opnieuw kan worden toegewezen, terwijl er nog 
schakels zijn die naar dit bestand wijzen. Wat voor problemen kunnen 
er optreden indien er een nieuw bestand wordt gemaakt in dezelfde op- 
slagruimte? Hoe kunnen deze worden vermeden? 


Sommige systemen heffen automatisch alle gebruikersbestanden op wan- 
neer een gebruiker zich afmeldt of wanneer een job eindigt, tenzij de 
gebruiker expliciet verzoekt deze te bewaren, terwijl andere systemen alle 
gebruikersbestanden bewaren tenzij de gebruiker expliciet verzoekt ze op 
te heffen. Bespreek de relatieve voordelen van elk van beide manieren. 


Ontwerpers van besturingssystemen zouden de grootte van hun modulen 
moeten beperken vanwege het nadelige effect op zaken als het mogelijke 
aantal fouten, de kosten die daaruit voortvloeien, onbetrouwbaarheid en 
complexiteit van het systeem. Er is daarom wat voor te zeggen dat in 
een bestandssysteem functies als het voorzien in verschillende bestands- 
structuren en toegangsmethoden het beste kunnen worden gerealiseerd 
door bibliotheekroutines in plaats van door het systeem zelf. Welke meer 
fundamentele functies zou u het systeem zelf laten doen? Licht uw ant- 
woord toe. 


Geef een voorbeeld van een toepassingsprogramma waarin gegevens in 
een bestand toegankelijk moeten zijn: 

a. Sequentieel-toegankelijk. 

b. Direct-toegankelijk. 


In vele systemen kan een daartoe geautoriseerde gebruiker een subadres- 
boek lezen en wegschrijven net zo als hij dat doet met bestanden. 

a. Welke beveiligingsproblemen kunnen er ontstaan? 

b. Bedenk een manier om deze beveiligingsproblemen te behandelen. 


Bedenk een methode om het mechanisme van het lopende adresboek 
efficiënt te implementeren. 


Zou u een adresboekstructuur met meerdere niveaus kunnen simuleren 
met een adresboekstructuur met één niveau waarin namen van willekeu- 
rige lengte gebruikt mogen worden? Als uw antwoord ’ja’ is, leg dan uit 
hoe en vergelijk deze twee methoden. Hoe zou uw antwoord zijn als de 
bestandsnamen beperkt zouden zijn tot zeven tekens? 


Opgaven 


3.8 


3.9 


3.10 


3.11 


3.12 


3.13 
3.14 


3.15 


Neem een bestand dat op dit moment uit 100 blokken bestaat. Hoeveel 
schijf-I/O-bewerkingen zijn er nodig met aaneengesloten, en geïndiceer- 
de toewijzingsstrategieën als één blok: 

vooraan wordt toegevoegd? 

middenin wordt toegevoegd? 

achteraan wordt toegevoegd? 

. vooraan wordt weggehaald? 

middenin wordt weggehaald? 

achteraan wordt weggehaald? 


mo aoe 


Sommige systemen geven de mogelijkheid van gezamenlijk gebruik van 
bestanden door één kopie van een bestand te bewaren, terwijl andere 
systemen verscheidene kopieën bewaren, één voor elk van de gebruikers 
die het bestand gezamenlijk gebruiken. Bespreek de relatieve voordelen 
van elk van beide manieren. 


Sommige systemen openen automatisch een bestand wanneer voor de 
eerste maal daarnaar wordt verwezen, en sluiten het bestand wanneer de 
job eindigt. Bespreek de voor- en nadelen van deze methode in verge- 
lijking met de meer traditionele waarin de gebruiker expliciet het bestand 
moet openen en sluiten. 


Men heeft voorgesteld dat er, in plaats van een toegangslijst voor elk 
bestand (welke gebruikers hebben toegang tot het bestand en hoe), een 
gebruikersbesturingslijst zou moeten zijn voor elke gebruiker (tot welke 
bestanden heeft een gebruiker toegang en hoe). Vergelijk de relatieve 
verdiensten van elk van beide manieren. 


Neem een systeem waarin de vrije ruimte wordt bijgehouden in een vrije- 

ruimtelijst. 

a. Stel dat de wijzer naar de vrije-ruimtelijst zoek is. Kan het systeem 
de vrije-ruimtelijst reconstrueren? 

b. Bedenk een manier die garandeert dat de wijzer nooit verloren raakt 
als gevolg van een storing in het geheugen. 


Leg de bedoeling uit van de open- en sluit-bewerkingen. 


Neem een programma dat de aaneengesloten, aaneengeschakelde en 
geindiceerde toewijzingsstrategieén ondersteunt. Welke criteria moeten 
worden gehanteerd om te beslissen welke strategie voor een bepaald be- 
stand moet worden gebruikt? 


Waarom moet de bittabel voor bestandstoewijzing op een massageheu- 
gen in plaats van in het hoofdgeheugen worden bewaard? 
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Neem een systeem met 5000 gebruikers. Stel dat u 4990 gebruikers toe- 

gang wilt laten hebben tot een bestand. 

a. Hoe zou u dit specificeren? 

b. Zou u een ander beveiligingsschema kunnen aangeven dat effectiever 
voor dit doel kan worden gebruikt? 


We hebben een bestandssysteem op een schijf met blokken van 512 
woorden. Stel dat ieder bestand een adresboekingang heeft waarin de 
bestandsnaam, het eerste blok (of eerste indexblok), de lengte van het 
bestand en de plaats van het laatste blok staan. De adresboekingang 
staat in het geheugen. Voor geïndiceerde toewijzing wijst de adresboek- 
ingang naar het eerste indexblok, dat op zijn beurt wijst naar 511 be- 
standsblokken en een wijzer naar het volgende indexblok. De volgende 
twee opdrachten moeten voor elk van de drie toewijzingsstrategieën, te 
weten aaneengesloten, aaneengeschakeld en geïndiceerd, worden uitge- 
voerd. 

a. Leg uit hoe de vertaling van logische naar fysieke adressen door het 
systeem wordt gedaan. 

b. Als we momenteel bij het logische blok 10 zijn (het laatste blok waar- 
toe toegang werd verkregen is blok 10) en toegang wensen tot logisch 
blok 4, hoeveel fysieke blokken moeten dan van de schijf worden 
gelezen? 


Eén probleem met aaneengesloten toewijzing is dat de gebruiker van 
tevoren genoeg ruimte voor elk bestand moet laten toewijzen. Indien 
het bestand groter wordt dan de toegewezen ruimte, moeten er speciale 
maatregelen worden genomen. Een oplossing is dat een bestandsstruc- 
tuur wordt gedefinieerd die uit een aanvankelijk aaneengesloten gebied 
(van een opgegeven grootte) bestaat. Wanneer dit vol is, definieert het 
besturingssysteem automatisch een overloopgebied dat geschakeld is aan 
het aanvankelijke aaneengesloten gebied. Wanneer het overloopgebied 
vol is, wordt automatisch een ander overloopgebied toegewezen. Verge- 
lijk deze implementatie van een bestand met de standaardimplementatie 
van aaneengesloten en aaneengeschakelde toewijzing. 


Bibliografische verwijzingen 


Een adresboekstructuur met meerdere niveaus werd voor het eerst geïmplemen- 
teerd in het Multics-systeem [Daley en Neumann 1965]. Andere systemen die 
gebruik maken van een adresboekstructuur met meerdere niveaus zijn onder meer 
Atlas [Wilkes 1975], TENEX [Bobrow et al. 1972] en Unix [Ritchie en Thompson 
1974]. Watson [1970], Organick [1972] en Katzan [1973] gaven een bespreking 
van de implementatie van adresboekstructuren. 

Technieken voor bestandsorganisatie werden besproken door Knuth [1973] 


Bibliografische verwijzingen 


en Lefkovitz [1969]. Chapin [1969] vergeleek verschillende technieken voor be- 
standsorganisatie. De verschillende manieren waarop een bestand georganiseerd 
kan zijn werden gepresenteerd door Dodd [1969] in een heel aardig leerzaam 
artikel. | 

Dynamische geheugentoewijzing wordt besproken door Knuth [1973, para- 
graaf 2.5], die op grond van simulatiestudies vond dat eerst-passend in het alge- 
meen superieur is aan best-passend. Verdere besprekingen worden gegeven door 
Shore [1975] en Bays [1977]. 

Hiérarchieén van I/O-functies werden besproken door Madnick en Alsop 
[1969], Shaw [1974, paragraaf 9.6], Tsichritzis en Bernstein [1974, paragraaf 6.1], 
Dependahl en Presser [1976] en Calingaert [1982, paragraaf 6.3]. 

De integriteit van bestandssystemen werd besproken door Wilkes [1975] en 
Fraser [1969, 1972] voor het Cambridge Multiple-Access systeem en door Or- 
ganick [1972] voor het Multics-systeem. 

Besprekingen op het niveau van een elementair leerboek worden gegeven 
door Shaw [1974, hoofdstuk 9], Tsichritzis en Bernstein [1974, hoofdstuk 6], Lis- 
ter [1979, hoofdstuk 6], Habermann [1976, hoofdstuk 9] en Calingaert [1982, 
hoofdstuk 9]. 
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CVE-WERKINDELING 


CVE-werkindeling is de basis van besturingssystemen met multiprogrammering. 
Door de CVE over te schakelen van het ene proces op het andere kan het bestu- 
ringssysteem de computer meer produktief maken. In dit hoofdstuk voeren we 
de elementaire begrippen van werkindeling in en geven we verschillende algorit- 
men voor CVE-werkindeling. Ook bekijken we het probleem van het kiezen van 
een algoritme voor een bepaald systeem. 


4.1 Overzicht multiprogrammering 


Het belangrijkste begrip in moderne besturingssystemen is zonder twijfel multi- 
programmering. Als we een aantal programma’s tegelijk in het geheugen hebben 
kunnen we ze de CVE gezamenlijk laten gebruiken. Deze opzet voert de efficiën- 
tie van het computersysteem op door meer werk in minder tijd klaar te krijgen. 

Het begrip multiprogrammering is betrekkelijk eenvoudig. Een job wordt 
uitgevoerd tot deze moet wachten, gewoonlijk op het gereedkomen van een ver- 
zoek om I/O. In een eenvoudig computersysteem zou de CVE dan gewoon zon- 
der werk zitten. Al deze wachttijd is verspild, er wordt geen nuttig werk gedaan. 
Met multiprogrammering trachten we deze tijd produktief te gebruiken. Ver- 
scheidene jobs worden op hetzelfde moment in het geheugen bewaard. Wanneer 
één job moet wachten neemt het besturingssysteem de CVE van die job af en 
geeft hem aan een andere job. Dit patroon zet zich voort. Elke keer dat een job 
moet wachten kan een andere job het gebruik van de CVE overnemen. 

De voordelen van multiprogrammering zijn een hogere CVE-gebruiksfactor 
en een grotere totale doorvoercapaciteit voor jobs. De doorvoercapaciteit is de 
hoeveelheid werk die gedurende een gegeven tijd wordt verricht (bijvoorbeeld 17 
jobs per uur). Stel, om een extreem voorbeeld te nemen, dat twee jobs, A en B, 
moeten worden uitgevoerd (zie figuur 4.1). Elke job draait één seconde en wacht 
dan één seconde. Dit patroon wordt 60 keer herhaald. Als we eerst job A draaien 
en dan job B, na elkaar, zal het vier minuten duren om de twee jobs te draaien 
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JOBA Bd 
start zonder werk; zonder werk; zonder werk; stop 
invoer invoer invoer 


Je: tt tp pe 
start zonder werk; zonder werk; zonder werk; stop 
invoer invoer invoer 


Figuur 4.1 
Twee jobs, A en B, die moeten worden uitgevoerd 


(zie figuur 4.2). Het draaien van job A duurt twee minuten, daarna duurt het 
draaien van job B twee minuten. 

De eigenlijke verwerking vindt echter plaats gedurende slechts twee mi- 
nuten van deze tijd; de andere twee minuten wordt er niets gedaan. Onze CVE- 
gebruiksfactor is slechts 50%. 

Als we op job A en job B multiprogrammering toepassen, kunnen we het 
prestatievermogen van het systeem aanmerkelijk verbeteren (zie figuur 4.3). We 
beginnen met job A, die gedurende één seconde draait. Dan, terwijl job A één 
seconde wacht, draaien we job B. Wanneer job B wacht, is job A gereed om te 
draaien. Nu is de tijdsduur voor het draaien van beide jobs slechts twee minuten 
en er is geen leeglooptijd van de CVE. Aldus hebben we de CVE-gebruiksfactor 
verbeterd van 50 naar 100%, waarbij we tegelijkertijd de doorvoertijd hebben 
verbeterd. Let erop dat job A niet eerder gereedkomt, maar dat job B in slechts 
de helft van de tijd klaarkomt. 

Dit voorbeeld is een extreem geval en zal hoogstwaarschijnlijk in de prak- 
tijk niet voorkomen. Het geeft echter wel een goede illustratie van het begrip 
multiprogrammering. In de volgende paragraaf gaan we veel dieper op multipro- 
grammering in. 


JOB A 


[4-7 Ln en Zn ee 


start zonder werk; zonder werk; zonder werk; stop 


JOBA invoer invoer invoer JOBA 
JOB B 
|------------=--+------- t+—1-7- 4-7-h/A-7-K 
wachtend start zonder werk; zonder werk; zonder werk; stop 
JOB B invoer invoer invoer JOB B 


Figuur 4.2 
Uitvoering van jobs zonder multiprogrammering 
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JBA dd 


start zonder zonder zonder stop 
werk; werk; werk; 
invoer invoer invoer 


start zonder werk; zonder werk; zonder werk; stop 
invoer invoer invoer 


Figuur 4.3 
Uitvoering van jobs met multiprogrammering 


4.2 Begrippen inzake werkindeling 


Werkindeling is een basisfunctie van het besturingssysteem, aangezien bijna alle 
faciliteiten van het computersysteem worden ingedeeld voordat ze worden ge- 
bruikt. De CVE is natuurlijk één van de hoofdfaciliteiten van een computersys- 
teem. Daarom staat de werkindeling voor de CVE centraal bij het ontwerpen van 
besturingssystemen. 


4.2.1 Basiscomponenten 


De CVE voert een groot aantal jobs of taken uit. Terwijl de voornaamste taak 
van de CVE het uitvoeren van gebruikersjobs en -programma’s is, is de CVE 
ook nodig voor andere systeemactiviteiten. Iedere actie van het computersysteem 
wordt op gang gebracht door de CVE. De CVE moet reageren op fouten-’vallen’, 
verzoeken van programma’s en I/O-onderbrekingen. Onderbrekingen kunnen 
worden veroorzaakt door aparte tekens op het toetsenbord van een terminal on- 
der tijddeling, of een kanaalprogramma dat grote blokken overbrengt tussen het 
geheugen en randapparatuur voor de massale opslag van gegevens. 

Een voortdurend probleem bij besturingssystemen is de vraag hoe we al 
die activiteiten van de CVE moeten noemen. Een systeem voor groepsgewijze 
verwerking voert jobs uit, terwijl een systeem met tijddeling gebruikersprogram- 
ma’s kent. Zelfs op een systeem met één gebruiker kan deze gebruiker verschillen- 
de programma’s tegelijkertijd draaien: één interactief programma en diverse pro- 
gramma’s voor groepsgewijze verwerking. Zelfs als de gebruiker slechts één pro- 
gramma tegelijk kan draaien, kan het nog wel nodig zijn dat het besturingssys- 
teem ondersteuning verleent aan zijn eigen interne activiteiten, zoals spool- 
verwerking. 

In veel opzichten lijken al die activiteiten op elkaar; dus noemen we ze 
allemaal processen. Een proces is een programma in uitvoering. Een programma 
voor groepsgewijze verwerking is een kenmerkend voorbeeld van een proces. Een 
gebruikersprogramma onder tijddeling is een proces. Een systeemtaak, zoals 
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spool-verwerking, is ook een proces. In verschillende besturingssystemen kunnen 
jobs, gebruikers, programma’s, taken of activiteiten, processen worden genoemd. 
Voorlopig kunnen we een proces zien als een job of een programma onder tijd- 
deling, maar het begrip is in feite algemener. Zoals we zullen zien in hoofdstuk 
9, zijn er bijvoorbeeld systeemaanroepen mogelijk die erin voorzien dat processen 
subprocessen creëren die dan gelijktijdig worden uitgevoerd. 

De termen job en proces kunnen in dit boek welhaast door elkaar worden 
gebruikt. Persoonlijk prefereren we de term proces, maar een groot deel van de 
theorie en terminologie van besturingssystemen werd ontwikkeld in een tijd dat 
de voornaamste bezigheid van besturingssystemen het verwerken van jobs was. 
Het zou misleidend zijn het gebruik van algemeen gangbare termen, waaronder 
het woord job (zoals job-werkindeling), te vermijden alleen omdat de term proces 
het woord job heeft verdrongen. 


CVE-I/O-actiecyclus 

Het succes van CVE-werkindeling hangt af van de volgende waargenomen eigen- 
schap van processen: de uitvoering van een proces is een cyclus van verwerking 
door de CVE en het wachten op I/O. Processen gaan voortdurend over van de 
ene in de andere toestand. De uitvoering van een proces begint met een CVE- 
‘actie’ (Engels: burst). Dit wordt gevolgd door een 1/O-actie, die gevolgd wordt 
door een CVE-actie, dan weer een I/O-actie, enzovoort. Uiteindelijk zal de laat- 
ste CVE-actie eindigen met een verzoek aan het systeem de uitvoering te beéin- 
digen, zonder dat er een nieuwe I/O-actie op volgt (zie figuur 4.4). 

Men heeft de duur van deze CVE-acties gemeten. Deze tijdsduur vertoont 
van proces tot proces en van computer tot computer grote verschillen; gewoonlijk 
lijkt de frequentiekromme op die in figuur 4.5. De kromme kan in het algemeen 
worden gekarakteriseerd als exponentieel of hyperexponentieel. Er is een zeer 
groot aantal zeer korte CVE-acties en een klein aantal zeer lange CVE-acties. 
Een I/O-gebonden programma zal gewoonlijk een paar zeer korte CVE-acties 
hebben. Een CVE-gebonden programma zou een paar zeer lange CVE-acties 
kunnen hebben. Deze verdeling kan van groot belang zijn bij het uitkiezen van 
een geschikt algoritme voor CVE-werkindeling. 


Procestoestand 
Een proces is een programma in uitvoering. Tijdens de uitvoering verandert de 
toestand van het proces. De toestand van een proces wordt bepaald door zijn 
momentele activiteit. De uitvoering van het proces is een afwisseling van CVE- 
en 1/O-acties, die beginnen en eindigen met een CVE-actie. Dus ieder proces kan 
in één van de volgende toestanden zijn: nieuw, actief, wachtend of gestopt. Deze 
toestanden zijn aanschouwelijk voorgesteld in figuur 4.6. 

In feite kunnen deze toestanden verder worden verfijnd. Aangezien ver- 
schillende processen de CVE samen kunnen gebruiken, kan een actief proces 
ofwel op de CVE wachten of aan de uitvoering erop bezig zijn. Een proces dat 
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Figuur 4.4 
Uitvoering is een afwisseling van CVE- en |/O-acties 


wacht op de CVE is gereed voor uitvoering. Een proces dat de CVE heeft toe- 
gewezen gekregen is in uitvoering. Een gedetailleerder toestandsdiagram is weer- 
gegeven in figuur 4.7. 


Procesbesturingsblok 

Elk proces wordt in het besturingssysteem gerepresenteerd door zijn eigen proces- 
besturingsblok (ook wel een taakbesturingsblok of job-besturingsblok genoemd; 
zie figuur 4.8). Een procesbesturingsblok (PBB) is een blok of record met gege- 
vens waarin veel stukjes informatie staan die met een bepaald proces verband 
houden, zoals: 


@ De procestoestand, die kan zijn: nieuw, gereed, in uitvoering, wachtend of 
gestopt, 

@ De programmateller, die het adres aangeeft van de volgende instructie die voor 
dit proces moet worden uitgevoerd. 

@ De CVE-registers, die in aantal en soort kunnen variëren, afhankelijk van de 
computerarchitectuur. Daaronder bevinden zich optelregisters, indexregisters 
en registers voor algemene doeleinden, plus mogelijke informatie betreffende 
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Figuur 4.5 


Histogram van de duur van CVE-acties 


de resultaatcode. Deze toestandsinformatie moet, samen met de program- 
mateller, worden opgeslagen wanneer er een onderbreking optreedt, zodat het 
proces daarna weer op de juiste wijze verder kan gaan (zie figuur 4.9). 

@ Geheugenbeheer-informatie, zoals basis- en grensregisters of paginatabellen 
(zie hoofdstuk 5). 

@ Boekhouding, zoals de gebruikte hoeveelheid CVE-tijd en werkelijke tijd, tijd- 
grenzen, rekeningnummers, job- of procesnummers, enzovoort. 

@ 1/O-statusinformatie, zoals uitstaande verzoeken om I/O, aan dit proces toe- 


Wachtend 


Figuur 4.6 
Procestoestandsdiagram 
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Gereed Gestopt 


Wachtend 


Figuur 4.7 
Verfijnd procestoestandsdiagram 


gewezen randapparatuur (zoals magneetbandeenheden), een lijst van open be- 
standen, enzovoort. 

@ Informatie voor de CVE-werkindeling, zoals de prioriteit van processen, wijzers 
naar werkindelingswachtrijen en andere parameters voor werkindeling. 


Het PBB doet eenvoudig dienst als opslagplaats voor alle mogelijke informatie 
die van proces tot proces kan verschillen. 
PBB’s moeten worden opgeslagen in het monitorgedeelte van het geheugen. 
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Figuur 4.8 
Procesbesturingsblok 
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Figuur 4.9 
De CVE kan van de ene naar de andere gebruiker worden overgeschakeld 


Dit geheugen kan op verschillende manieren worden beheerd. Verreweg de ge- 
makkelijkste benadering is het maximum aantal processen van tevoren op te ge- 
ven en op statische wijze genoeg ruimte toe te wijzen voor alle PBB’s. In het 
algemeen echter zal het aantal PBB’s mettertijd veranderen. Daarom zou een 
beleid van dynamisch geheugenbeheer beter kunnen zijn. De systeemontwerper 
moet de extra flexibiliteit en het mogelijk beter benutten van het geheugen afwe- 
gen tegen de complexere algoritmen en de kans op fouten of het toewijzen van 
teveel geheugen. 


4.2.2 Wachtrijen voor werkindeling 


Het doel van multiprogrammering is dat er op elk moment een proces in uitvoe- 
ring is, met het oog op een zo hoog mogelijke CVE-gebruiksfactor. In een systeem 
met één CVE (uniprocessor-systeem) zal nooit meer dan één proces in uitvoering 
zijn. Zijn er meer processen, dan zal de rest moeten wachten tot de CVE vrij is 
en ander werk kan krijgen. De processen die ‘gereed’ zijn (voor verwerking) en 
wachten om te worden uitgevoerd, worden bewaard op een lijst die men de 
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gereed-wachtrij noemt. In het algemeen is dit een aaneengeschakelde lijst. De kop 
van de gereed-wachtrij bevat wijzers naar het eerste en het laatste PBB in de lijst. 
Ieder PBB heeft een veld voor een wijzer die naar het volgende proces in de 
gereed-wachtrij wijst. 

We moeten opmerken dat de gereed-wachtrij niet noodzakelijk een eerst- 
in-eerst-uit (First-In-First-Out, of FIFO) wachtrij is, zoals die worden gebruikt in 
leerboeken over gegevensstructuren. Zoals we zullen zien wanneer we de diverse 
algoritmen voor werkindeling nagaan, kan een gereed-wachtrij worden opgezet 
als een FIFO-wachtrij, een prioriteitswachtrij, een boom, een stapel, of gewoon 
een niet-geordende aaneengeschakelde lijst. Alles bijeengenomen echter staan al 
de processen in de gereed-wachtrij te wachten tot ze een kans krijgen om op de 
CVE te worden uitgevoerd. 

Er zijn nog andere wachtrijen in het systeem (zie figuur 4.10). Wanneer een 
proces de CVE krijgt toegewezen, zal het een tijdje in uitvoering zijn en tenslotte 
ofwel eindigen of wachten op het gereedkomen van een I/O-verwerking. Het 
verzoek om I/O kan gedaan worden aan een geheel aan dat proces ter beschik- 
king staande terminal, of aan een randapparaat dat met andere processen gedeeld 


Kop van de rij PBB nr. 7 PBB nr. 2 


een- | Staat +—a PBBnr.3 PBB nr. 14 PBB nr. 6 


Figuur 4.10 
De gereed-wachtrij en diverse randapparaat-wachtrijen 
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wordt, zoals een schijf. Aangezien er veel processen in het systeem zijn, kan de 
schijf bezig zijn met het verzoek om I/O van een ander proces. Dus is het moge- 
lijk dat het proces op de schijf moet wachten. De lijst van de processen die wach- 
ten op een bepaald randapparaat wordt een randapparaat-wachtrij genoemd. Elk 
randapparaat heeft zijn eigen randapparaat-wachtrij. Als het randapparaat een 
alleen aan dat proces ter beschikking staand randapparaat is, zoals een terminal 
onder tijddeling, zal er nooit meer dan één proces in de randapparaat-wachtrij 
staan. Betreft het een apparaat voor gemeenschappelijk gebruik, dan kunnen er 
verschillende processen in de randapparaat-wachtrij voorkomen. 

Een veel gebruikte voorstelling bij de bespreking van de CVE-werkindeling 
is een wachtrij-diagram zoals figuur 4.11. Elke rechthoek stelt een wachtrij voor. 
Er komen twee soorten wachtrijen in voor: de gereed-wachtrij en een groep rand- 
apparaat-wachtrijen. De cirkels stellen de systeemfaciliteiten voor die de wacht- 
rijen bedienen, en de pijlen geven aan welke weg de processen door het systeem 
volgen. 

Een proces komt het systeem vanuit de buitenwereld binnen en wordt in 
de gereed-wachtrij gezet. Het wacht in de gereed-wachtrij totdat het wordt ge- 
selecteerd voor de CVE. Uiteindelijk wordt het door het randapparaat geholpen 
en keert het terug naar de gereed-wachtrij. Een proces gaat door met deze CVE- 
I/O-cyclus tot het klaar is; dan verlaat het het systeem. 

Omdat we ons op dit punt hoofdzakelijk bezighouden met de CVE-werkin- 
deling, zullen we de details van het meervoudige subsysteem van de randappara- 
tuur verwaarlozen en deze vervangen door één I/O-wachtrij en I/O-dienstver- 
lener (zie figuur 4.12). Over I/O-werkindeling volgt meer in de hoofdstukken 7 


en 8. 
5| Gereed-wachtrij (ove) 
(vo) L/O-wachtrij 
Figuur 4.11 


CVE-werkindeling voorgesteld door middel van een wachtrij-diagram 
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Figuur 4.12 
Vereenvoudigd wachtrij-diagram 


4.2.3 Programma’s voor werkindeling 


Een besturingssysteem heeft vele werkindelingsprogramma’s. Er zijn twee pro- 
gramma’s voor CVE-werkindeling: het programma voor werkindeling op lange 
termijn en het programma voor werkindeling op korte termijn. 

De lange-termijn-werkindeler (of job-werkindelingsprogramma; Engels: job 
scheduler) bepaalt welke jobs voor verwerking tot het systeem worden toegelaten. 
In een systeem voor groepsgewijze verwerking worden vaak meer jobs toegelaten 
dan er meteen kunnen worden uitgevoerd. Deze jobs worden met spool-verwer- 
king op een randapparaat voor massale opslag van gegevens gezet (gewoonlijk 
een schijf), waar zij worden bewaard om later te worden verwerkt. De lange- 
termijn-werkindeler selecteert jobs uit deze jobpot en laadt ze in het geheugen 
om te worden uitgevoerd. De korte-termijn-werkindeler (of CVE-werkindelings- 
programma; Engels: CPU scheduler) selecteert uit de jobs in het geheugen die 
jobs die voor uitvoering gereed zijn en wijst de CVE aan één van hen toe. 

Het hoofdonderscheid tussen deze beide programma’s voor werkindeling is 
de frequentie waarmee ze worden uitgevoerd. De korte-termijn-werkindeler moet 
zeer dikwijls een nieuw proces voor de CVE selecteren. Een proces kan misschien 
een paar milliseconden in uitvoering zijn voor het moet wachten vanwege een 
verzoek om I/O. Vaak wordt de korte-termijn-werkindeler minstens eens per 10 
milliseconden uitgevoerd. Wegens de zeer korte tijdsduur tussen twee uitvoerin- 
gen moet de korte-termijn-werkindeler heel snel zijn. Als het 1 milliseconde duurt 
om te beslissen dat een proces gedurende 10 milliseconden moet worden uitge- 
voerd, dan wordt 1/(10+1) = 9% van de CVE gebruikt (verspild) alleen maar 
om het werk in te delen. 

De lange-termijn-werkindeler daarentegen is veel minder vaak aan het 
werk. Er kunnen minuten liggen tussen de aankomst van nieuwe jobs in het sys- 
teem. De lange-termijn-werkindeler bestuurt het multiprogrammeringsniveau (het 
aantal processen in het geheugen). Als het multiprogrammeringsniveau stabiel is, 
moet de gemiddelde aankomstsnelheid van jobs die het systeem binnenkomen 
gelijk zijn aan de gemiddelde vertreksnelheid van jobs die het systeem verlaten. 
Daarom is het mogelijk dat de lange-termijn-werkindeler alleen wordt aangeroe- 
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pen wanneer een job het systeem verlaat. Vanwege de langere tijdsduur tussen 
twee uitvoeringen kan de lange-termijn-werkindeler het zich veroorloven meer 
tijd te gebruiken om te beslissen welke job geselecteerd wordt voor uitvoering. 

Het kan ook van meer belang zijn dat de lange-termijn-werkindeler een 
zorgvuldige selectie maakt. In het algemeen kunnen de meeste jobs worden om- 
schreven óf als I/O-gebonden óf als CVE-gebonden. Het is belangrijk dat de 
lange-termijn-werkindeler een goede job-mengverhouding van 1/O-gebonden en 
CVE-gebonden jobs selecteert. Zouden alle jobs I/O-gebonden zijn, dan is de 
gereed-wachtrij bijna altijd leeg en heeft de korte-termijn-werkindeler weinig te 
doen. Zijn alle jobs CVE-gebonden, dan is de I/O-wachtrij bijna altijd leeg en is 
het systeem opnieuw uit balans. Het systeem met de beste prestatie heeft een 
combinatie van CVE-gebonden en I/O-gebonden jobs. 

Op sommige systemen zal de lange-termijn-werkindeler niet veel voorstel- 
len of geheel ontbreken. Systemen met tijddeling bijvoorbeeld hebben vaak geen 
lange-termijn-werkindeler, maar zetten gewoon elk nieuw proces in het geheugen 
voor de korte-termijn-werkindeler. De stabiliteit van deze systemen hangt af van 
óf een fysieke beperking (zoals een beperkt aantal beschikbare terminals) óf van 
de zichzelf aanpassende natuur van de menselijke gebruikers. Als het prestatie- 
vermogen te slecht wordt, zullen sommige gebruikers gewoon opstappen en iets 
anders gaan doen. 

Sommige systemen, speciaal die met virtueel geheugen of met tijddeling, 
kunnen nog een tussenliggend niveau van werkindeling te zien geven. Deze mid- 
dellange-termijn-werkindeler is als diagram weergegeven in figuur 4.13. De sleutel- 
gedachte achter. een middellange-termijn-werkindeler is dat het soms voordelig 
kan zijn processen uit het geheugen (en uit de actieve wedijver om de CVE) te 
verwijderen, om aldus het multiprogrammeringsniveau naar beneden te brengen. 
Op een later moment kan het proces in het geheugen worden teruggebracht en 
kan het weer verder gaan waar het gebleven was. Dit procédé noemt men vaak 
programmaverwisseling of procesverwisseling. Het proces wordt door de middel- 
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Figuur 4.13 
Wachtrij-diagram na toevoeging van werkindeling op middellange termijn 
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lange-termijn-werkindeler uit het geheugen gezet en later weer binnengebracht. 
Procesverwisseling kan nodig zijn om de job-mengverhouding te verbeteren, of 
omdat een verandering in de benodigde geheugenruimte de beschikbare geheu- 
gencapaciteit ontoereikend maakt, zodat geheugen moet worden vrijgegeven. 
Programmaverwisseling wordt uitvoeriger besproken in hoofdstuk 5. 

Een andere component die meespeelt in de CVE-werkindelingsfunctie is 
het verdeelprogramma (Engels: dispatcher). Het verdeelprogramma is de module 
die feitelijk het beheer van de CVE overgeeft aan het proces dat door de korte- 
termijn-werkindeler werd geselecteerd. Deze functie omvat het laden van de re- 
gisters van het proces, het overschakelen op de gebruiker-modus en het springen 
naar de juiste plaats in het gebruikersprogramma om dit opnieuw te starten. Het 
is duidelijk dat het verdeelprogramma zo snel mogelijk moet zijn. 


4.3 Algoritmen voor werkindeling 


De CVE-werkindeling houdt zich bezig met het beslissen aan welk proces in de 
gereed-wachtrij de CVE moet worden toegewezen. Er zijn veel verschillende algo- 
ritmen voor CVE-werkindeling. In deze paragraaf zullen we verscheidene van 
deze algoritmen beschrijven. 


4.3.1 Prestatiecriteria 


Verschillende algoritmen hebben verschillende eigenschappen en kunnen de ene 
groep processen bevoordelen tegenover de andere. Bij de keuze welk algoritme 
in een bepaalde situatie gebruikt moet worden moeten de eigenschappen van de 
verschillende algoritmen worden bekeken. 

Men heeft tal van criteria voor het vergelijken van algoritmen voor CVE- 
werkindeling voorgesteld. Het kan bij het bepalen van het beste algoritme een 
groot verschil uitmaken welke kenmerken voor deze vergelijking worden ge- 
bruikt. Men gebruikt onder meer de volgende criteria: 


@ CVE-gebruiksfactor. Wanneer de CVE erg duur is, willen we deze zoveel moge- 
lijk aan het werk houden. De CVE-gebruiksfactor kan variëren van 0 tot 100%. 
In een echt systeem moet deze liggen tussen de 40% (voor een lichtbelast sys- 
teem) en 90% (voor een zwaarbelast systeem). 

@ Doorvoercapaciteit. Als de CVE bezig is komt er werk klaar. Eén maat voor 
werk is het aantal jobs dat gereedkomt per tijdseenheid: de doorvoercapaciteit. 
Voor lange jobs kan dit aantal op één job per uur liggen; voor korte transacties 
zou de doorvoorcapaciteit kunnen komen op tien jobs per seconde. 

© Turnaround-tijd. Vanuit het gezichtspunt van een bepaalde job is hét crite- 
rium: hoe lang duurt het om die job uit te voeren. Het tijdinterval dat ligt 
tussen het tijdstip van het indienen tot het moment dat de job klaar is, is de 


4.3 Algoritmen voor werkindeling 


turnaround-tijd. De turnaround-tijd is de som van de perioden van (1) wach- 
ten om in het geheugen te komen, (2) wachten in de gereed-wachtrij, (3) de 
uitvoering op de CVE en (4) het wachten op I/O. 

@ Responstijd. In een interactief systeem is turnaround-tijd misschien niet het 
beste criterium. Dikwijls kan een proces vrij vroegtijdig enige uitvoer produce- 
ren en doorgaan met het berekenen van nieuwe resultaten, terwijl de voorgaan- 
de resultaten worden uitgevoerd naar de gebruiker. Daarom is een andere maat 
de tijd gerekend vanaf het indienen van een verzoek tot de eerste respons 
wordt geproduceerd. Deze maat, responstijd genoemd, is de hoeveelheid tijd 
die nodig is tot het begin van die respons, maar niet de tijd nodig voor het 
uitvoeren van die respons. De turnaround-tijd wordt in het algemeen beperkt 
door de snelheid van het uitvoerapparaat. 


Hebben we eenmaal een criterium voor vergelijking geselecteerd, dan willen 
we dit gewoonlijk optimaliseren. Het is wenselijk de CVE-gebruiksfactor en de 
doorvoercapaciteit zo groot mogelijk en de turnaround-tijd zo klein mogelijk te 
maken. In de meeste gevallen wordt de gemiddelde waarde geoptimaliseerd. Het 
kan soms echter wenselijk zijn de minimum- of maximumwaarden te optimali- 
seren in plaats van het gemiddelde. Bijvoorbeeld, om te garanderen dat alle ge- 
bruikers goede service ontvangen, willen we wellicht de maximale responstijd zo 
klein mogelijk houden. 

Men heeft ook de suggestie naar voren gebracht dat het voor interactieve 
systemen (zoals systemen met tijddeling) belangrijker is de variantie in de res- 
ponstijd te minimaliseren in plaats van de gemiddelde responstijd. Een systeem 
met een redelijke en voorspelbare responstijd kan als beter worden beschouwd 
dan een systeem dat gemiddeld sneller is maar aan grote veranderingen onderhe- 
vig. Er is heel weinig werk verricht op het gebied van algoritmen voor CVE- 
werkindeling om de variantie te minimaliseren. 

Bij het bespreken van de verschillende algoritmen voor CVE-werkindeling 
willen we hun werking toelichten. Een nauwkeurige toelichting moet rekening 
houden met vele jobs, waarbij elke job een opeenvolging vormt van verscheidene 
honderden CVE- en I/O-acties. Om de toelichting simpel te houden geven we 
een aantal voorbeelden met slechts één actie per job. Eén vergelijkingsmaatstaf 
is de gemiddelde turnaround-tijd: hoe lang duurt het om het werk voor deze 
jobs in te delen en ze uit te voeren? Uitgebreidere vergelijkingsmethoden worden 
besproken in paragraaf 4.4. 


4.3.2 Wie-het-Eerst-Komt-het-Eerst-Maalt 


Verreweg het eenvoudigste algoritme voor CVE-werkindeling is Wie-het-Eerst- 
Komt-het-Eerst-Maalt (WEKEM). Dat wil zeggen dat het proces dat het eerst om 
de CVE vraagt de CVE het eerst toegewezen krijgt. WEKEM kan gemakkelijk 
worden geïmplementeerd met behulp van een FIFO-wachtrij. Wanneer een pro- 
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ces in de gereed-wachtrij aankomt wordt het procesbesturingsblok aan de staart 
van de wachtrij geschakeld. Wanneer de CVE vrij is, wordt deze toegewezen aan 
het eerste proces in de wachtrij. Het proces in uitvoering wordt dan uit de gereed- 
wachtrij verwijderd. De code voor WEKEM-werkindeling is eenvoudig te schrij- 
ven en te begrijpen. 

Het prestatievermogen van WEKEM is‘echter vaak heel slecht. Neem eens 
de volgende drie jobs. Stel dat we voor elke job de lengte van de volgende CVE- 
actie weten. Dan kunnen we de gemiddelde turnaround-tijd voor het behandelen 
van deze drie CVE-acties berekenen. 


Job Duur van de actie 
l 24 
2 3 
3 3 


Als de jobs aankomen in de volgorde 1, 2, 3, en worden behandeld volgens 
WEKEM, krijgen we het resultaat dat u ziet in de volgende Gantt chart. 


27 ic: 30 


0 24 


De turnaround-tijd voor job 1 is 24; voor job 2, 27; en voor job 3, 30. Dus de 
gemiddelde turnaround-tijd is (24+ 27 + 30)/3 = 27. Als de jobs evenwel aanko- 
men in de volgorde 2, 3, 1, laat de volgende Gantt chart de resultaten zien: 


0 3 6 30 


De gemiddelde turnaround-tijd is nu (30+3+6)/3 = 13: een aanzienlijke ver- 
mindering. Dus is de gemiddelde turnaround-tijd van WEKEM in het algemeen 
niet minimaal en hij kan ook aanzienlijk variëren. 

Wat is nu het prestatievermogen van WEKEM in een dynamische situatie? 
Stel dat we één CVE-gebonden job hebben en vele I/O-gebonden jobs. Bij het 
circuleren van de jobs door het systeem kan het onderstaande scenario het gevolg 
zijn. De CVE-gebonden job krijgt de CVE en houdt deze vast. Gedurende deze 
tijd zullen alle andere jobs met hun I/O gereedkomen en in de gereed-wachtrij 
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komen om te wachten tot de CVE vrijkomt. Terwijl ze in de gereed-wachtrij staan 
te wachten, staat de randapparatuur niets te doen. Tenslotte eindigt de CVE- 
gebonden job zijn CVE-actie en gaat naar een randapparaat. Al de I/O-gebonden 
jobs die heel korte CVE-acties hebben, worden snel uitgevoerd en gaan terug 
naar de I/O-wachtrijen. Op dit punt aangekomen zit de CVE zonder werk. De 
CVE-gebonden job gaat dan terug naar de gereed-wachtrij en krijgt de CVE toe- 
gewezen. Opnieuw staan al de I/O-gebonden jobs in de gereed-wachtrij te wach- 
ten tot de CVE-gebonden job klaar is. Dit is een konvooi-effect: alle andere 
processen wachten erop dat het ene grote proces van de CVE af gaat. Dit effect 
heeft een lagere gebruiksfactor voor CVE en randapparatuur tot gevolg dan mo- 
gelijk zou zijn indien de kleinere jobs eerst mochten gaan. 


4.3.3 Kortste-Job-Eerst 


Een andere benadering van CVE-werkindeling is het Kortste-Job-Eerst (KJE) 
algoritme. Kortste-Job-Eerst legt een verband tussen iedere job en de lengte van 
zijn volgende CVE-actie. Wanneer de CVE beschikbaar is wordt hij toegewezen 
aan de job met de kleinste volgende CVE-actie. Als twee jobs even grote volgende 
CVE-acties hebben, wordt WEKEM gebruikt. 

Neem bijvoorbeeld de volgende verzameling jobs: 


Job Duur van de actie 
] 6 
2 3 
3 8 
4 7 


Door gebruik te maken van Kortste-Job-Eerst zouden we het werk voor deze jobs 
indelen volgens de volgende Gantt chart: 


De gemiddelde turnaround-tijd is 13. 

Het kan worden bewezen dat Kortste-Job-Eerst optimaal is in deze zin dat 
het voor een gegeven verzameling jobs de kleinst mogelijke gemiddelde wachttijd 
oplevert. Het bewijs laat zien dat wanneer een korte job vóór een lange gaat, dit 
de wachttijd van de korte job meer vermindert dan de wachttijd van de lange job 
„toeneemt (zie figuur 4.14). Dientengevolge neemt de gemiddelde wachttijd af. 
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Figuur 4.14 
Het bewijs dat KJE optimaal is 


De echte moeilijkheid met Kortste-Job-Eerst schuilt hierin: hoe weten we 
de lengte van de volgende CVE-actie? Voor job-werkindeling (lange termijn) in 
een systeem voor groepsgewijze verwerking kunnen we de job-tijdslimiet gebrui- 
ken. Op deze wijze worden de gebruikers gemotiveerd de job-tijdslimiet nauw- 
keurig te schatten, aangezien een lagere waarde een snellere turnaround kan bete- 
kenen. (Een te lage waarde zal een ‘tijdslimiet overschreden’-fout veroorzaken en 
het opnieuw indienen van de job noodzakelijk maken.) Kortste-Job-Eerst wordt 
bij job-werkindeling veelvuldig gebruikt. 

Al is Kortste-Job-Eerst optimaal, het kan niet worden geïmplementeerd op 
het niveau van de (korte-termijn) CVE-werkindeling. Het is onmogelijk de lengte 
van de volgende CVE-actie te weten. Eén manier is te proberen de Kortste-Job- 
Eerst-werkindeling te benaderen. Al weten we de lengte van de volgende CVE- 
actie niet, misschien zijn we toch in staat deze waarde bij benadering te voorspel- 
len. We verwachten eigenlijk dat de volgende CVE-actie een lengte zal hebben 
die ongeveer gelijk is aan die van de voorgaande actie. Dus kunnen we, door bij 
benadering de lengte van de volgende CVE-actie te berekenen, de job eruit pik- 
ken met de kortste voorspelde CVE-actie. 

De lengte van de volgende CVE-actie wordt gewoonlijk voorspeld door een 
exponentieel gemiddelde te nemen van de gemeten lengten van voorgaande CVE- 
acties. Laat tn de lengte zijn van het nde CVE-actie, en laat 1„+1 onze voorspelde 
waarde zijn voor de volgende CVE-actie. Definieer dan, voor Os<asl: 


al 


Tn+1 = Qtr + (1— a)r. 


Deze formule definieert een exponentieel gemiddelde. De waarde van t„ bevat onze 
meest recente informatie; in T» is de minder recente historie opgeslagen. De pa- 
rameter « regelt het relatieve gewicht dat we toekennen aan de recente en minder 
recente historie in onze voorspelling. Als a = 0, dan is T‚+1 = m, en heeft de 
recente historie geen effect (er wordt van uitgegaan dat de huidige omstandighe- 
den van voorbijgaande aard zijn); als a = 1, dan is Tn+1 = fn, en doet alleen de 
meest recente CVE-actie ertoe (van de minder recente historie wordt veronder- 
steld dat deze oud is en niet ter zake doende). Meer gebruikelijk is « = 1⁄2, zodat 
recente historie en minder recente historie een even groot gewicht krijgen. Figuur 
4.15 laat een exponentieel gemiddelde met a = % zien. De aanvangswaarde To 
kan worden gedefinieerd als een constante of een globaal systeem-gemiddelde. 
Om het gedrag van een exponentieel gemiddelde te begrijpen, kunnen we 
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Figuur 4.15 


Het voorspellen van de lengte van de volgende CVE-actie met behulp van een exponentieel 
gemiddelde 


de formule voor 1„+1 uitwerken door voor Ta de formule zelf te substitueren, waar- 
bij we vinden: 


Tn+1 = Qtr + (l—a)atre-1 + ... + (l-avVatj; +... 


Daar a en (1 — a) beide kleiner zijn dan 1, heeft iedere volgende term een kleiner 
gewicht dan zijn voorganger. 


4.3.4 Prioriteit 


Kortste-Job-Eerst is een speciaal geval van het algemene algoritme voor werkin- 
deling gebaseerd op prioriteit. Aan iedere job wordt een prioriteit toegekend en 
de CVE wordt toegewezen aan de job met de hoogste prioriteit. Werkindeling 
voor jobs met gelijke prioriteit is WEKEM. Een KJE-algoritme is gewoon een 
prioriteitsalgoritme waarin de prioriteit (p) het omgekeerde is van de lengte van 
de (voorspelde) volgende CVE-actie (t): p = 1/1. Hoe langer de CVE-actie, hoe 
lager de prioriteit, en omgekeerd. 

Let erop dat we in de bespreking over werkindeling de uitdrukkingen hoge 
en lage prioriteit bezigen. Prioriteiten worden gewoonlijk uitgedrukt in getallen 
uit een vast interval, zoals 0 tot 7 of 0 tot 4095. Er bestaat echter geen algemene 
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overeenstemming over de vraag of 0 de hoogste of de laagste prioriteit is. Som- 
mige systemen gebruiken lage getallen om lage prioriteit aan te geven; andere 
systemen hebben lage getallen voor hoge prioriteit. Dit verschil kan tot enige 
verwarring leiden. 

Prioriteiten kunnen intern of extern worden gedefinieerd. Intern gedefi- 
nieerde prioriteiten gebruiken een of meer meetbare grootheden voor het bereke- 
nen van de prioriteit van een proces. Men heeft bijvoorbeeld tijdslimieten, geheu- 
geneisen, het aantal open bestanden en de verhouding tussen de gemiddelde leng- 
ten van I/O- en CVE-acties, gebruikt voor het berekenen van prioriteiten. Exter- 
ne prioriteiten worden vastgesteld volgens buiten het besturingssysteem gelegen 
criteria, zoals hoeveel geld wordt betaald voor computergebruik en de pot waaruit 
dit geld komt, de afdeling waarvoor het werk gebeurt, en andere externe, vaak 
politieke, factoren. 

Een belangrijk probleem met algoritmen voor werkindeling die op prioriteit 
gebaseerd zijn is blokkering voor onbepaalde tijd of verhongering. Een proces dat 
gereed is voor uitvoering, maar de CVE niet heeft en erop staat te wachten, kan 
als geblokkeerd worden beschouwd. Een werkindeling op grond van prioriteit 
kan sommige processen met lage prioriteit voor onbepaalde tijd op de CVE laten 
wachten. In een zwaarbelast computersysteem kan een constante stroom van 
processen met een hogere prioriteit een proces met lagere prioriteit beletten ooit 
de CVE te krijgen. In het algemeen kunnen er dan twee dingen gebeuren. Of de 
job zal ten langen leste draaien (zoals om 2 uur zaterdagnacht wanneer het sys- 
teem tenslotte lichtbelast is), of het computersysteem zal stuklopen en alle onge- 
draaide jobs met lage prioriteit verliezen. (Er gaat een gerucht dat, toen de 7094 
op het MIT in 1973 buiten bedrijf gesteld werd, men een job met lage prioriteit 
vond die in 1967 was ingediend en nog niet gedraaid was.) 

Een andere oplossing voor het probleem van het voor onbepaalde tijd blok- 
keren van jobs met lage prioriteit is veroudering. Veroudering is een techniek die 
bestaat uit het geleidelijk een hogere prioriteit geven aan jobs die in het systeem 
al lang staan te wachten. Als bijvoorbeeld de prioriteiten lopen van 0 (laag) tot 
127 (hoog), zouden we iedere vijftien minuten de prioriteit van een wachtende 
job met 1 kunnen verhogen. Uiteindelijk zou zelfs een job met een aanvangsprio- 
riteit van 0 de hoogste prioriteit in het systeem hebben en worden uitgevoerd. In 
feite zou het niet meer dan 32 uur duren voordat een job met prioriteit 0 verou- 
dert tot een job met prioriteit 127. 


4.3.5 Algoritmen met voortijdige onderbreking 


WEKEM, Kortste-Job-Eerst, en prioriteitsalgoritmen, zoals tot dusver beschre- 
ven, zijn algoritmen zonder voortijdige onderbreking (Engels: non-preemptive). Dat 
wil zeggen, heeft een proces de CVE eenmaal toegewezen gekregen, dan kan het 
de CVE houden tot het deze weer wenst vrij te geven, hetzij door beëindiging, 
hetzij door een verzoek om I/O. WEKEM werkt zonder voortijdige onder- 
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breking, maar de twee andere algoritmen kunnen worden gewijzigd tot algorit- 
men met voortijdige onderbreking. 

Kortste-Job-Eerst kan al of niet voortijdig onderbreken. Deze vraag doet 
zich voor op het moment dat een job in de gereed-wachtrij aankomt terwijl een 
voorgaande job in uitvoering is. De nieuwe job kan een kortere volgende CVE- 
actieduur hebben dan wat is overgebleven van die van de job die nu in uitvoering 
is. Een KJE-algoritme met voortijdige onderbreking zal de CVE voortijdig ontne- 
men (Engels: to preempt) aan de dan in uitvoering zijnde job, terwijl een KJE- 
algoritme zonder voortijdige onderbreking de job die momenteel in uitvoering is 
zijn CVE-actie zal laten beëindigen. Kortste-Job-Eerst met voortijdige onder- 
breking wordt soms Kortste-Resterende-Tijd-Eerst genoemd. 

Werkindeling op grond van prioriteit kan eveneens al of niet voortijdig 
onderbreken. Wanneer een job in de gereed-wachtrij aankomt (als gevolg van het 
gereedkomen van de I/O van zijn vorige verzoek om I/O bijvoorbeeld), wordt 
zijn prioriteit vergeleken met de prioriteit van het op dat ogenblik in uitvoering 
zijnde proces. Een algoritme voor werkindeling gebaseerd op prioriteit dat voor- 
tijdig onderbreekt zal beslag leggen op de CVE indien de prioriteit van het zojuist 
aangekomen proces hoger is dan de prioriteit van het dan in uitvoering zijnde 
proces. Een algoritme voor werkindeling gebaseerd op prioriteit dat niet voor- 
tijdig onderbreekt zal het nieuwe proces gewoon vooraan in de gereed-wachtrij 
plaatsen. 

Algoritmen voor CVE-werkindeling zonder voortijdige onderbreking (in 
het bijzonder WEKEM) roepen vooral problemen op voor systemen met tijd- 
deling. In een systeem met tijddeling is het heel belangrijk dat elke gebruiker met 
regelmatige tussenpozen de beschikking over de CVE krijgt. Het zou rampzalig 
zijn als één proces de CVE langere tijd zou mogen houden. 

Neem als voorbeeld de volgende 4 jobs. 


Job Aankomsttijd Duur van de actie 
l 0 8 
2 l 4 
3 2 9 
4 3 5 


Als de jobs op de vermelde tijden in de gereed-wachtrij aankomen en de CVE 
voor de aangegeven duur nodig hebben, dan illustreert de volgende Gantt chart 
Kortste-Job-Eerst met voortijdige onderbreking die daaruit volgt. 


‚j— voortijdige onderbreking 


01 5 10 17 26 
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Job 1 wordt gestart op tijdstip 0, aangezien het de enige job in de wachtrij is. Job 
2 komt aan op tijdstip 1. De resterende tijd voor job 1 (7 tijdseenheden) is groter 
dan de tijd die job 2 nodig heeft (4 tijdseenheden), dus de CVE wordt voortijdig 
aan job 1 ontnomen en aan job 2 toegewezen. De gemiddelde turnaround-tijd 
in dit voorbeeld is ((17—0) + (5—1) + (26—2) + (10—3))/4 = 52/4 = 13 
tijdseenheden. Kortste-Job-Eerst zonder voortijdige onderbreking zou een ge- 
middelde turnaround-tijd van 14,25 tot gevolg hebben. 


4.3.6 Rondlopende wachtrij (round-robin) 


Het algoritme voor werkindeling bij toerbeurt of met rondlopende wachtrij (Engels: 
round-robin) is speciaal ontworpen voor systemen met tijddeling. Men definieert 
een kleine tijdseenheid, een tijd-quantum of tijdschijfje (Engels: time-slice) ge- 
noemd. Een tijd-quantum bedraagt in het algemeen tussen de 10 en 100 millise- 
conden. De gereed-wachtrij wordt behandeld als een cirkelvormige wachtrij. De 
CVE-werkindeler gaat de gereed-wachtrij rond, waarbij hij de CVE aan elk pro- 
ces toewijst voor de duur van maximaal één tijd-quantum. 

Voor de implementatie van werkindeling met rondlopende wachtrij wordt 
de gereed-wachtrij bijgehouden als een FIFO-wachtrij van processen. Nieuwe 
processen worden aan het einde van de gereed-wachtrij toegevoegd. De CVE- 
werkindeler neemt de eerste job uit de gereed-wachtrij, zet een tijdregister op één 
tijd-quantum en brengt het proces in uitvoering. Er kunnen dan twee dingen 
gebeuren. Het proces kan een CVE-actie hebben die kleiner is dan het tijd-quan- 
tum. In dit geval geeft het proces de CVE vrijwillig op, door een verzoek om 
I/O te doen of door te eindigen. We gaan dan verder met de volgende job in de 
gereed-wachtrij. 

In het andere geval, als de CVE-actie van het momenteel in uitvoering zijn- 
de proces langer duurt dan het tijd-quantum, zal het tijdregister afgaan en een 
onderbreking veroorzaken die de besturing overdraagt aan het besturingssysteem. 
De registers van het onderbroken proces worden dan opgeslagen in het proces- 
besturingsblok en het proces wordt achteraan in de gereed-wachtrij gezet. Het 
programma voor CVE-werkindeling selecteert dan de volgende job in de gereed- 
wachtrij en geeft deze het volgende tijd-quantum. 

Kijk bijvoorbeeld eens naar de volgende groep jobs die al eerder werd ge- 
bruikt om de WEKEM-werkindeling te illustreren. 


Job Duur van de actie 
l 24 
2 k 
3 3 
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Als we een tijd-quantum ter grootte van 4 gebruiken, volgt hieruit de onder- 
staande werkindeling bij toerbeurt: 


0 4 7 10 14 18 22 26 30 


Job 1 krijgt de eerste 4 tijdseenheden. Daar hij er nog 20 nodig heeft, wordt de 
CVE hem na het eerste tijd-quantum voortijdig ontnomen en aan de volgende 
job in de wachtrij, job 2, gegeven. Omdat job 2 geen 4 eenheden nodig heeft, 
stopt deze voor het tijd-quantum afgelopen is. De CVE wordt dan aan het volgen- 
de proces, job 3, gegeven. Nadat iedere job een tijd-quantum heeft gehad, wordt 
de CVE voor de duur van weer één tijd-quantum teruggegeven aan job 1. De 
gemiddelde turnaround-tijd is 47/3 œ 16. 

In het algoritme voor werkindeling met rondlopende wachtrij krijgt geen 
enkel proces de CVE langer dan één tijd-quantum aan één stuk. Als de duur 
van een CVE-actie van een proces het tijd-quantum overschrijdt, wordt de CVE 
voortijdig ontnomen aan het proces en wordt dit teruggezet in de gereed-wachtrij. 
Het algoritme voor werkindeling bij toerbeurt is een algoritme met voortijdige 
onderbreking. 

Als er n processen in de gereed-wachtrij zijn en het tijd-quantum gelijk is 
aan q, dan krijgt elk proces 1/n van de CVE-tijd in brokken van hoogstens 
q tijdseenheden tegelijk. Geen proces hoeft langer te wachten dan (n— 1) maal 
q tijdseenheden tot zijn volgende tijd-quantum. Als er bijvoorbeeld vijf processen 
zijn, met een tijd-quantum van 20 milliseconden, zou elk proces hoogstens 20 
milliseconden per 100 milliseconden krijgen. 

Het prestatievermogen van werkindeling bij toerbeurt hangt sterk af van 
het tijd-quantum. In het ene uiterste geval, als het quantum zeer groot (oneindig) 
is, is werkindeling bij toerbeurt hetzelfde als WEKEM. Als het tijd-quantum zeer 
klein is (zeg 1 microseconde), wordt werkindeling bij toerbeurt het gemeenschap- 
pelijk gebruik van de verwerkingseenheid (Engels: processor sharing) genoemd; de 
indruk bestaat dan (theoretisch) dat elk van de n processen zijn eigen verwer- 
kingseenheid heeft op 1/n van de snelheid van de werkelijke verwerkingseenheid. 
Deze benadering wordt in de apparatuur gebruikt in de CDC 6600 voor de imple- 
mentatie van tien randprocessoren met slechts één apparatuursysteem en tien stel 
registers [Thornton 1970]. De apparatuur voert één instructie uit voor een groep 
registers en gaat dan naar de volgende groep. Deze cyclus wordt vervolgd zodat 
het gevolg is: tien langzame processoren in plaats van één snelle. (Omdat de 
verwerkingseenheid veel sneller is dan het geheugen en met iedere instructie één 
of meer geheugenverwijzingen gepaard gaan, zijn de processoren in feite niet veel 
langzamer dan één enkele processor zou zijn.) 
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In de programmatuur hebben we echter andere problemen. Vooral aan het 
eind van elk tijd-quantum krijgen we een onderbreking door het tijdregister. Het 
verwerken van de onderbreking om de CVE op een ander proces over te schake- 
len vereist het opslaan van alle registers voor het oude proces en het laden van 
de registers voor het nieuwe proces. Deze taak staat bekend als contextomschake- 
ling. De tijd nodig voor contextomschakeling is louter vaste last (overhead). Deze 
varieert van machine tot machine, afhankelijk van de snelheid van het geheugen, 
het aantal registers en het bestaan van speciale instructies (zoals één enkele in- 
structie voor het laden of opbergen van alle registers). Gewoonlijk duurt dit 10 
tot 100 milliseconden. 

Laten we, om het effect van de contextomschakelingstijd op het prestatie- 
vermogen van werkindeling bij toerbeurt te illustreren, eens aannemen dat we 
slechts één job hebben met een duur van 10 tijdseenheden. Als het quantum 12 
tijdseenheden is, eindigt de job in minder dan 1 tijd-quantum, zonder overhead. 
Als het tijd-quantum 6 tijdseenheden is, heeft de job 2 quanta nodig met als 
gevolg een contextomschakeling. Als het tijd-quantum 1 tijdseenheid is vinden er 
9 contextomschakelingen plaats, die de uitvoering van de job dienovereenkomstig 
vertragen (zie figuur 4.16). 

Dus willen we dat het tijd-quantum groot is in vergelijking met de context- 
omschakelingstijd. Als deze ongeveer 10% van het tijd-quantum bedraagt, zal 
ongeveer 10% van de CVE-tijd worden besteed aan contextomschakelingstijd. 

De turnaround-tijd hangt ook af van het tijd-quantum (zie figuur 4.17). 
Deze kan worden verbeterd indien de meeste jobs hun volgende CVE-actie af- 
krijgen binnen een enkel tijd-quantum. Als bijvoorbeeld drie jobs gegeven zijn 
van elk 10 tijdseenheden en een quantum van 1 tijdseenheid, is de gemiddelde 
turnaround-tijd 29. Als het tijd-quantum evenwel 10 is, zakt de turnaround-tijd 


Job-duur = 10 Quantum Context- 
omschakelingen 
0 10 
6 1 
0 
6 10 


Figuur 4.16 
Een kleiner tijd-quantum doet het aantal contextomschakelingen toenemen. 
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Figuur 4.17 
De gemiddelde turnaround-tijd verandert met het tijd-quantum 


naar 20. Als de contextomschakelingstijd hierbij opgeteld wordt, wordt alles voor 
een klein tijd-quantum nog erger, daar er meer contextomschakelingen nodig 
zijn. 

Aan de andere kant, als het tijd-quantum te groot is, degenereert werkinde- 
ling bij toerbeurt to WEKEM. Een vuistregel is dat 80% van de CVE-acties korter 
moeten duren dan het tijd-quantum. 


4.3.7 Wachtrijen met meerdere niveaus 


Men heeft een andere klasse van algoritmen voor werkindeling ontwikkeld voor 
situaties waarin jobs gemakkelijk in verschillende groepen kunnen worden inge- 
deeld. Een veel gebruikte indeling is bijvoorbeeld die van voorgrond-jobs (interac- 
tieve jobs) en achtergrond-jobs (batch jobs). Deze twee soorten jobs hebben ge- 
heel verschillende responstijden nodig, en zouden daarom onder verschillende 
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algoritmen voor werkindeling kunnen vallen. Bovendien kunnen voorgrond-jobs 
voorrang (extern gedefinieerd) hebben op achtergrond-jobs. 

Een algoritme voor werkindeling met meerdere wachtrijen deelt de gereed- 
wachtrij op in afzonderlijke wachtrijen (zie figuur 4.18). Jobs worden permanent 
toegewezen aan één wachtrij, in het algemeen op grond van een of andere eigen- 
schap van de job, zoals geheugengrootte of het soort job. Elke wachtrij heeft zijn 
eigen algoritme voor werkindeling. Er zouden bijvoorbeeld afzonderlijke wacht- 
rijen gebruikt kunnen worden voor voorgrond- en achtergrond-jobs. Voor de 
voorgrond-wachtrij zou de werkindeling bij toerbeurt kunnen plaatsvinden, ter- 
wijl dit voor de achtergrond-wachtrij gebeurt volgens WEKEM. 

Bovendien moet er een werkindeling zijn voor de wachtrijen onderling. Dit 
is gewoonlijk een werkindeling met voortijdige onderbreking en met vaste prio- 
riteiten. De voorgrond-wachtrij kan bijvoorbeeld absolute prioriteit hebben ten 
opzichte van de achtergrond-wachtrij. 

Als voorbeeld van een algoritme voor werkindeling met meerdere wacht- 
rijen geven we een OS/MFT-systeem met vijf wachtrijen: 


@ Systeemjobs 

@ Interactieve programma’s 

@ Interactieve tekstopmaaksessies 
@ Achtergrond-jobs 

@ Jobs van studenten 


Elke wachtrij heeft absolute prioriteit ten opzichte van wachtrijen met la- 
gere prioriteit. Er zou geen job in bijvoorbeeld de achtergrond-wachtrij kunnen 
draaien, tenzij de wachtrijen voor systeemjobs, interactieve jobs en interactieve 
tekstopmaaksessies allemaal leeg waren. Als een interactieve job de gereed- 
wachtrij zou binnenkomen terwijl er een achtergrond-job draaide, zou de CVE 
voortijdig aan de achtergrond-job worden ontnomen. 

Een andere mogelijkheid is dat we aan elk van de wachtrijen een tijdschijfje 
geven. Elke wachtrij krijgt een zeker gedeelte van de CVE-tijd, die dan kan wor- 
den verdeeld over de verschillende processen in de wachtrij. In het geval van 
een voorgrond- en achtergrond-wachtrij kan bijvoorbeeld 80% van de CVE-tijd 
worden gegeven aan werkindeling bij toerbeurt van processen in de voorgrond- 
wachtrij, terwijl werkindeling volgens WEKEM van de processen in de achter- 
grond-wachtrij 20% van de CVE krijgt. 


4.3.8 Wachtrijen met meerdere niveaus en terugkoppeling 


Gewoonlijk worden jobs in een algoritme voor werkindeling met meerdere wacht- 
rijen jobs bij hun binnenkomst in het systeem permanent aan een wachtrij toe- 
gewezen. Jobs gaan niet van de ene wachtrij naar de andere. Als er bijvoorbeeld 
afzonderlijke wachtrijen zijn voor voorgrond- en achtergrond-jobs, zouden jobs 
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Interactief 
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laagste prioriteit 


Figuur 4.18 
Werkindeling met meerdere wachtrijen 


niet van de ene naar de andere wachtrij gaan, omdat het voorgrond of achter- 
grondkarakter van jobs niet verandert. 

Een wachtrij met meerdere niveaus en terugkoppeling evenwel laat een job 
van het ene naar het andere niveau verhuizen. Het idee daarachter is de jobs te 
splitsen in jobs met verschillende kenmerken voor CVE-acties. Als een job teveel 
CVE-tijd gebruikt verhuist hij naar een wachtrij met lagere prioriteit. Deze me- 
thode zorgt ervoor dat I/O-gebonden en interactieve jobs in de wachtrijen met 
hogere prioriteit blijven. Op soortgelijke wijze zal een job die te lang moet wach- 
ten in een wachtrij met lagere prioriteit kunnen opschuiven naar een wachtrij met 
hogere prioriteit. 

Neem bijvoorbeeld een programma voor werkindeling met een wachtrij met 
meerdere niveaus en terugkoppeling, waarvan de deelwachtrijen genummerd zijn 
van 0 tot 2 (zie figuur 4.19). Het programma voor werkindeling voert eerst alle 
jobs in wachtrij 0 uit. Alleen wanneer wachtrij 0 leeg is, zal het programma jobs 
in wachtrij 1 uitvoeren. Net zo gaat het met jobs in wachtrij 2, die alleen worden 
uitgevoerd wanneer de wachtrijen 0 en 1 leeg zijn. Een job die aankomt in wacht- 
rij 1 zal de CVE voortijdig ontnemen aan een job van wachtrij 2. Een job van 
wachtrij 1 zal op zijn beurt de CVE voortijdig verliezen aan een job die aankomt 
in wachtrij 0. 
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Quantum = 8 


Quantum = 16 


WEKEM 


Figuur 4.19 
Wachtrij met meerdere niveaus en terugkoppeling 


Een job die nieuw aankomt in de gereed-wachtrij wordt in wachtrij 0 gezet. 
Een job in wachtrij 0 krijgt een tijd-quantum van 8 milliseconden. Als hij niet 
klaarkomt binnen deze tijd, verhuist hij naar het einde van wachtrij 1. Als wacht- 
rij 0 leeg is, krijgt de job aan het begin van wachtrij 1 een quantum van 16 
milliseconden. Als hij niet klaarkomt, wordt de CVE hem voortijdig ontnomen 
en verhuist hij naar wachtrij 2. Jobs in wachtrij 2 worden alleen dan volgens 
WEKEM gedraaid wanneer de wachtrijen 0 en 1 leeg zijn. 

Dit algoritme voor werkindeling geeft de hoogste prioriteit aan alle jobs 
met een CVE-actie van 8 milliseconden of minder. Zo’n job zal snel de CVE 
krijgen, zijn CVE-actie beëindigen, en naar zijn volgende I/O-actie gaan. Jobs 
die meer dan 8, maar minder dan 24, milliseconden nodig hebben worden ook 
snel behandeld, al is het met een lagere prioriteit dan kortere jobs. Langdurige 
jobs zakken automatisch naar wachtrij 2 en worden volgens WEK EM behandeld 
met de CVE-cycli die over zijn van wachtrijen 0 en 1. 

In het algemeen wordt een programma voor werkindeling met meerdere 
wachtrijen en terugkoppeling door de volgende parameters gedefinieerd: 


@ Het aantal wachtrijen. 

@ Het algoritme voor werkindeling voor elke wachtrij. 

@ Een methode om te bepalen wanneer een job moet worden bevorderd tot een 
wachtrij met hogere prioriteit. 

@ Een methode om te bepalen wanneer een job moet worden gedegradeerd tot 
een wachtrij met lagere prioriteit. 

@ Een methode om te bepalen in welke wachtrij een job komt wanneer deze 
dienstverlening nodig heeft. 


4.4 Waardebepaling van de algoritmen 


De definitie van een programma voor werkindeling met meerdere wachtrijen en 
terugkoppeling maakt dit tot het meest algemene algoritme voor CVE-werkinde- 
ling. Dit kan zo worden opgezet dat het overeenkomt met een specifiek systeem 
dat men bezig is te ontwerpen. Helaas zijn er ook een paar methoden nodig om 
de waarden voor alle parameters zo te kiezen dat het beste programma voor 
werkindeling wordt gedefinieerd. Hoewel een wachtrij met meerdere niveaus en 
terugkoppeling het meest algemene ontwerp is, is het ook het meest complexe. 


4.4 Waardebepaling van de algoritmen 


Hoe selecteren we een algoritme voor CVE-werkindeling voor een bepaald sys- 
teem? Zoals we hebben gezien in paragraaf 4.3 zijn er veel algoritmen voor werk- 
indeling, elk met zijn eigen parameters. Daarom kan het selecteren van een algo- 
ritme heel moeilijk zijn. 

Het eerste probleem is het bepalen van de criteria die men bij het kiezen 
van een algoritme moet aanleggen. Zoals we in paragraaf 4.3.1 zagen, worden 
criteria vaak opgesteld met behulp van de CVE-gebruiksfactor, de responstijd of 
de doorvoercapaciteit. Voor het kiezen van een algoritme moeten we de relatieve 
belangrijkheid van deze maatstaven bepalen. In onze criteria kunnen we diverse 
maatregelen opnemen, zoals: 


@ Maak de CVE-gebruiksfactor zo hoog mogelijk, onder de beperking dat de 
maximaal toegestane responstijd 1 seconde is. 

@ Maak de doorvoercapaciteit zo groot mogelijk, zodat de turnaround-tijd (ge- 
middeld) lineair evenredig is met de totale uitvoeringstijd. 


Nadat de selectie-criteria gedefinieerd zijn, willen we de waarde bepalen 
van de diverse algoritmen in kwestie. Er is een aantal verschillende methoden 
voor waardebepaling, waarvan we in de volgende paragrafen een beschrijving 
geven. 


4.4.1 Analytische waardebepaling 


Een belangrijke groep van methoden voor waardebepaling wordt analytische 
waardebepaling genoemd. Analytische waardebepaling gebruikt het algoritme en 
de werkbelasting van het systeem voor het produceren van een formule die, of 
een getal dat, het prestatievermogen van het algoritme voor die werkbelasting 
bepaalt. 


Deterministische modellen 
Eén soort analytische waardebepaling is het gebruik maken van deterministische 
modellen. Deze methode gaat uit van een van tevoren vastgestelde werkbelasting 
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en definieert dan voor die werkbelasting het prestatievermogen van elk algoritme. 
Stel bijvoorbeeld dat we de hieronder aangegeven werkbelasting hebben. 
Alle vijf jobs komen aan op tijdstip 0, in de aangegeven volgorde. 


Job Duur van de actie 
l 10 
2 29 
3 3 
4 7 
5 12 


Als we nu de algoritmen voor werkindeling volgens WEKEM, Kortste-Job-Eerst 
en ’bij toerbeurt’ (quantum = 10) op deze verzameling jobs toepassen, welk algo- 
ritme geeft dan de kleinste gemiddelde wachttijd? 

Met WEKEM zouden we de jobs uitvoeren als: 


De gemiddelde wachttijd is 140/5 = 28. 
Met Kortste-Job-Eerst (zonder voortijdige onderbreking) voeren we de jobs 
uit als: fies 
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De gemiddelde wachttijd is 65/5 = 13. 

Met werkindeling bij toerbeurt (quantum = 10) starten we job 2, maar 
ontemen hem voortijdig de CVE na 10 tijdseenheden en zetten hem achteraan in 
de wachtrij. 


De gemiddelde wachttijd is 115/5 = 23. 

We zien dat in dit geval Kortste-Job-Eerst minder dan de helft van de ge- 
middelde wachttijd heeft van WEKEM; ’bij toerbeurt’ heeft een waarde daartus- 
senin. 

Deterministische modellen zijn eenvoudig en snel. Ze geven exacte getallen, 
zodat de algoritmen vergeleken kunnen worden. Men moet echter wel exacte 
getallen invoeren en de antwoorden zijn alleen op die gevallen van toepassing. 
Het belangrijkste gebruik van deterministische modellen ligt in het beschrijven 
van de algoritmen voor werkindeling en het leveren van voorbeelden. In gevallen 
waarin we dezelfde programma’s voortdurend opnieuw zouden draaien en hun 
verwerkingsbehoeften exact kunnen meten, zouden we een deterministisch model 
kunnen gebruiken om een algoritme voor werkindeling uit te kiezen. Gerekend 
over een groep gevallen kan een deterministisch model tendensen aangeven die 
kunnen worden geanalyseerd en afzonderlijk bewezen. Er kan, bijvoorbeeld voor 
de beschreven omgeving (alle jobs en hun tijden zijn beschikbaar op tijdstip 0), 
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worden aangetoond dat Kortste-Job-Eerst altijd de minste wachttijd zal ople- 
veren. 

In het algemeen is het gebruik van deterministische modellen te specifiek 
om in de meeste gevallen erg bruikbaar te zijn. Er is teveel exacte kennis vereist 
en de resultaten hebben beperkte bruikbaarheid. 


Mathematisch-statistische modellen 

De jobs die op vele systemen gedraaid worden variëren van dag tot dag en er is 
dus geen statische groep jobs (en tijden) die voor een deterministisch model ge- 
bruikt kunnen worden. Wat echter wel kan worden bepaald is de verdeling van 
CVE- en I/O-acties. Deze verdelingen kunnen worden gemeten en dan worden 
benaderd of gewoon geschat. Het resultaat is een wiskundige formule die de 
waarschijnlijkheid beschrijft dat een CVE-actie van een bepaalde lengte zal op- 
treden. Gewoonlijk is deze verdeling exponentieel en is dan bepaald door zijn 
gemiddelde. Evenzo moet de verdeling van de tijden waarop jobs in het systeem 
aankomen (de aankomsttijd-verdeling) worden gegeven. Met behulp van deze 
twee verdelingen is het mogelijk de gemiddelde doorvoercapaciteit, gebruiksfac- 
tor, wachttijd, enzovoort, voor de meeste algoritmen te berekenen. 

Het computersysteem wordt beschreven als een netwerk van bedienings- 
faciliteiten of loketten (Engels: servers). Voor elk loket staat een wachtrij van 
wachtende jobs. De CVE is een loket waarvoor jobs in de gereed-wachtrij staan 
te wachten, zoals ook het I/O-systeem een loket is waarvoor de randapparaat- 
wachtrijen staan. Wanneer we de aankomst- en bedieningssnelheden weten, kun- 
nen we de gebruiksfactor, de gemiddelde wachtrijlengte, de gemiddelde wacht- 
tijd, enzovoort, berekenen. Dit studiegebied noemt men de wachttijdtheorie van 
netwerken. 

Laat n bijvoorbeeld de gemiddelde wachtrijlengte zijn (waarin niet begre- 
pen is de job die bediend wordt), W de gemiddelde wachttijd in de wachtrij, en 
\ de gemiddelde aankomstsnelheid voor nieuwe jobs in de wachtrij. Dan kunnen 
we verwachten dat gedurende de tijd W dat een job moet wachten, N X W nieuwe 
jobs in de rij zullen aankomen. Als het systeem in een stabiele toestand verkeert, 
moet het aantal jobs dat de rij verlaat even groot zijn als het aantal jobs dat 
aankomt. Derhalve geldt: 


n= NX W. 


Deze vergelijking staat bekend als de formule van Little. De formule van Little is 
bijzonder nuttig omdat deze voor elk algoritme voor werkindeling en voor iedere 
verdeling van aankomsttijden geldt. 

We kunnen de formule van Little gebruiken om één van de drie variabelen 
te berekenen als we de andere twee weten. Bijvoorbeeld, als we weten dat er 
(gemiddeld) 7 jobs per seconde aankomen, en dat er gewoonlijk 14 jobs in de 
wachtrij staan, dan kunnen we de gemiddelde wachttijd per job uitrekenen: 2 
seconden. 
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De wachttijdtheorie kan voor het vergelijken van algoritmen voor werkin- 
deling heel nuttig zijn, maar heeft ook zijn beperkingen. Op dit moment is de 
groep algoritmen en verdelingen die ermee kan worden behandeld tamelijk be- 
perkt. De wiskunde van gecompliceerde algoritmen of verdelingen kan heel moei- 
lijk zijn om mee te werken. Daarom zijn verdelingen van aankomst- en bedie- 
ningstijden vaak op een onrealistische, maar wiskundig handzame manier gedefi- 
nieerd. In het algemeen is het ook nodig een aantal van elkaar onafhankelijke 
onderstellingen te maken, die niet nauwkeurig hoeven te zijn. Dus zijn mathema- 
tisch-statistische modellen voor het kunnen berekenen van het antwoord dikwijls 
slechts een benadering van het echte systeem. Als gevolg daarvan kan de nauw- 
keurigheid van het antwoord wel eens twijfelachtig zijn. 


4.4.2 Simulatie 


Om een nauwkeuriger waardebepaling van algoritmen voor werkindeling te krij- 
gen wordt dikwijls gebruik gemaakt van simulatie. Om te simuleren is het nodig 
een model van het computersysteem te programmeren. Gegevensstructuren in 
een programma stellen de hoofdcomponenten in een systeem voor. Het simulatie- 
programma kent een variabele die een klok voorstelt, en naarmate zijn waarde 
wordt opgehoogd wijzigt het simulatieprogramma de toestand van het systeem, 
om de aktiviteiten van de randapparatuur, de jobs en het programma voor werk- 
indeling te weerspiegelen. Bij het voortschrijden van de simulatie worden statis- 
tieken verzameld en afgedrukt om aan te geven wat de prestatie is van het algorit- 
me. 

De gegevens die de simulatie op gang brengen kunnen op verschillende 
manieren worden gegenereerd. De meest voorkomende methode maakt gebruik 
van een generator van toevalsgetallen, die zo geprogrammeerd is dat jobs, CVE- 
actietijden, aankomst- en vertrektijden, enzovoort, volgens waarschijnlijkheids- 
verdelingen worden gegenereerd. De verdelingen kunnen wiskundig (uniform, 
exponentieel, Poisson) of empirisch gedefinieerd zijn. Om een verdeling em- 
pirisch te definiëren, moeten metingen van het echte systeem dat men in studie 
heeft worden gedaan. De meetresultaten kunnen dan worden gebruikt om de 
werkelijke verdeling van gebeurtenissen in het echte systeem te definiëren. Deze 
verdeling kan dan worden gebruikt om de simulatie te sturen. 

Een door verdelingen gestuurde simulatie kan echter onnauwkeurig zijn; 
dit komt doordat er in het echte systeem verbanden zijn tussen opeenvolgende 
gebeurtenissen. De frequentieverdeling geeft alleen aan hoe vaak gebeurtenissen 
zich voordoen, maar zegt niets over de volgorde waarin ze optreden. Om dit 
probleem te corrigeren kan men gebruik maken van detailverslagen (traces) op 
magneetband. Een detailverslag kan worden gemaakt door het werkelijke sys- 
teem te observeren en de volgorde van de werkelijke gebeurtenissen op magneet- 
band vast te leggen (zie figuur 4.20). Deze reeks wordt dan gebruikt om de si- 
mulatie te sturen. Detailverslagen op magneetband vormen een uitstekende ma- 
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Waardebepaling van CVE-werkindelers door middel van simulatie. 
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nier om twee algoritmen te vergelijken in het verwerken van precies dezelfde 
verzameling werkelijke invoergegevens. Deze methode kan voor deze invoergege- 
vens zeer nauwkeurige resultaten geven. 

Simulatie kan echter zeer kostbaar zijn; vaak is daarvoor uren computertijd 
nodig. Een gedetailleerdere simulatie geeft nauwkeuriger resultaten, maar vereist 
ook meer computertijd. Bovendien kunnen detailverslagen op magneetband grote 
hoeveelheden geheugenruimte vereisen. Het ontwerpen, coderen en foutvrij ma- 
ken van het simulatieprogramma kan een heel karwei zijn. 


4.4.3 Implementatie 


Zelfs simulatie heeft een beperkte nauwkeurigheid. De enige volledig nauwkeu- 
rige manier om de waarde van een algoritme voor werkindeling te bepalen is het 
te coderen en aan te brengen in het besturingssysteem om te zien hoe het werkt. 
Deze aanpak zet het algoritme in het werkelijke systeem zodat de waardebepaling 
ervan onder echte praktijkomstandigheden kan plaatsvinden. 

Het voornaamste bezwaar zit hierin dat deze benadering duur is. De prijs 
die moet worden betaald ligt niet alleen in het coderen van het algoritme, het 
wijzigen van het besturingssysteem om dit algoritme te ondersteunen, en de ver- 
eiste gegevensstructuren, maar ook in hoe de gebruikers reageren op een bestu- 
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ringssysteem dat voortdurend aan wijziging onderhevig is. De meeste gebruikers 
zijn niet geïnteresseerd in het bouwen van een beter besturingssysteem; zij willen 
alleen maar hun jobs gedraaid zien en de resultaten gebruiken. Een besturingssys- 
teem dat voortdurend verandert helpt de gebruikers niet hun werk gedaan te 
krijgen. 

De andere moeilijkheid bij de waardebepaling van elk algoritme is dat de 
omgeving waarin het algoritme wordt gebruikt verandert. De omgeving verandert 
niet alleen op de gebruikelijke wijze, doordat nieuwe programma’s worden ge- 
schreven en de sóorten problemen zich wijzigen, maar ook als gevolg van het 
prestatievermogen van het programma voor werkindeling. Als voorrang wordt 
gegeven aan korte jobs, kan een gebruiker een grotere job wel splitsen in een 
verzameling kleinere jobs. Als interactieve jobs voorrang krijgen boven niet- 
interactieve jobs, kunnen gebruikers overgaan op een interactief gebruik. 

Hier is een voorbeeld. Een systeem probeerde automatisch processen als 
interactief of niet-interactief te classificeren door te kijken naar de hoeveelheid 
terminal-I/O. Als een proces over een periode van 1 seconde geen in- of uitvoer 
op de terminal deed, werd het geclassificeerd als niet-interactief en verhuisde het 
naar een wachtrij met lagere prioriteit. Dit had tot gevolg dat een programmeur 
zijn programma’s zó wijzigde dat deze met regelmatige tussenpozen van minder 
dan 1 seconde een willekeurig teken naar de terminal schreven. Het systeem gaf 
zijn programma’s een hoge prioriteit, ook al had de uitvoer naar de terminal 
totaal geen betekenis. 


4.5 Werkindeling voor meer dan één processor 


Onze bespreking van CVE-werkindeling heeft zich hoofdzakelijk toegespitst op 
het indelen van werk voor de CVE in een systeem met één processor. Als er meer 
CVE's beschikbaar zijn, is het probleem van de werkindeling dienovereenkomstig 
complexer. Men heeft veel mogelijkheden geprobeerd en, evenals met werkinde- 
ling voor één CVE, er is geen oplossing die de beste is. 

Een belangrijke factor is het soort processoren waarmee men te maken 
heeft. De processoren kunnen identiek zijn (en aldus een homogeen systeem vor- 
men) of verschillend zijn (een heterogeen systeem). Als de processoren verschil- 
lend zijn, zijn de mogelijkheden betrekkelijk beperkt. Elke processor heeft zijn 
eigen wachtrij en zijn eigen algoritme voor werkindeling. Jobs worden intrinsiek 
gekenmerkt door hun structuur; zij moeten op een bepaalde processor gedraaid 
worden. Een programma dat geschreven is in de PDP-11 assembleertaal kan niet 
worden gedraaid op een IBM Serie/1; het moet worden gedraaid op een PDP- 
11. Vandaar dat de processoren op zichzelf staan; en elke processor kan zijn 
eigen werk indelen. 

_ Als verschillende identieke processoren beschikbaar zijn, kan gedeelde 
werkbelasting plaatsvinden. Het zou mogelijk zijn een aparte wachtrij voor elke 
processor te maken. In dit geval echter zou de ene processor zonder werk kunnen 
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zitten, met een lege wachtrij, terwijl een andere processor erg hard bezig is. Om 
deze situatie te voorkomen wordt een gemeenschappelijke gereed-wachtrij ge- 
bruikt. Alle jobs komen in één wachtrij en kunnen aan elke processor worden 
toegewezen. 

In zo’n opzet kunnen twee benaderingen voor werkindeling worden ge- 
bruikt. De ene benadering is dat elke processor zijn eigen werkindeling heeft. 
Elke processor inspecteert de gereed-wachtrij en selecteert een proces voor uit- 
voering. Zoals we in hoofdstuk 9 zullen zien moet elke processor, als we meer 
dan één processor hebben die alle tot een gemeenschappelijke gegevensstructuur 
toegang willen krijgen en deze willen bijwerken, zeer zorgvuldig worden gepro- 
grammeerd. We moeten ervoor zorgen dat geen twee processoren hetzelfde proces 
selecteren, en dat er geen processen uit de wachtrij verloren gaan. De andere 
benadering vermijdt dit probleem door één processor tot werkindeler voor de 
andere processoren te benoemen, en zo bestaat er dan een meester/slaaf- 
structuur. 


4.6 Samenvatting 


CVE-werkindeling is het proces van het selecteren van een wachtend proces en 
het toewijzen van de CVE aan dat proces. Ieder proces wordt gerepresenteerd 
door een procesbesturingsblok. De procesbesturingsblokken kunnen aaneenge- 
schakeld worden om wachtrijen van processen te vormen. Er zijn twee hoofdgroe- 
pen van wachtrijen in een besturingssysteem: 1/O-wachtrijen en de gereed-wacht- 
rij. De gereed-wachtrij bevat al de processen die gereed zijn voor uitvoering en 
wachten op de CVE. 

Job-werkindeling is het selecteren van jobs die mogen wedijveren om de 
CVE te krijgen. Gewoonlijk wordt job-werkindeling sterk beïnvloed door over- 
wegingen met betrekking tot het toewijzen van systeemfaciliteiten, speciaal met 
betrekking tot het geheugenbeheer. CVE-werkindeling is het selecteren van één 
proces uit de gereed-wachtrij. De CVE wordt toegewezen aan het door het ver- 
deelprogramma (dispatcher) geselecteerde proces. 

Werkindeling volgens Wie-het-Eerst-Komt-het-Eerst-Maalt (WEKEM) is 
het eenvoudigste algoritme voor werkindeling, maar het kan er de oorzaak van 
zijn dat korte jobs moeten wachten op heel lange jobs. Van werkindeling volgens 
Kortste-Job-Eerst (KJE) kan worden bewezen dat dit optimaal is in deze zin dat 
het de kortste gemiddelde wachttijd oplevert. Kortste-Job-Eerst is moeilijk te 
implementeren, omdat het moeilijk te voorspellen valt wat de lengte zal zijn van 
de volgende CVE-actie. Kortste-Job-Eerst is een speciaal geval van het algemene 
algoritme voor werkindeling gebaseerd op prioriteit, dat eenvoudig de CVE toe- 
wijst aan het proces met de hoogste prioriteit. Zowel werkindeling gebaseerd op 
prioriteit als volgens Kortste-Job-Eerst lijden aan verhongering. Veroudering is 
een techniek om verhongering te voorkomen. 

Werkindeling bij toerbeurt is meer geschikt voor een systeem met tijddeling. 


Opgaven 


Bij toerbeurt is een algoritme met voortijdige onderbreking, WEKEM werkt zon- 
der voortijdige onderbreking. Kortste-Job-Eerst en algoritmen die op prioriteit 
gebaseerd zijn kunnen al of niet met voortijdige onderbreking werken. Werkinde- 
ling bij toerbeurt wijst de CVE toe aan het eerste proces in de gereed-wachtrij 
voor q tijdseenheden, waarin q het tijd-quantum is. Na q tijdseenheden wordt de 
CVE voortijdig aan het proces ontnomen en wordt dit achteraan in de gereed- 
wachtrij geplaatst. Het belangrijkste probleem is het kiezen van het tijd-quantum. 
Als het tijd-quantum te groot is, degenereert werkindeling bij toerbeurt tot 
WEKEM; als het tijd-quantum te klein is, ontstaat er een te grote overhead in 
de vorm van contextomschakelingstijd. 

Met wachtrijen met meerdere niveaus kan men verschillende algoritmen 
voor verschillende groepen jobs gebruiken. Een interactieve voorgrond-wachtrij 
met werkindeling bij toerbeurt, en een achtergrond-wachtrij met WEKEM- 
werkindeling wordt het meest gebruikt. Wachtrijen met terugkoppeling geven de 
mogelijkheid dat jobs van de ene naar de andere wachtrij verhuizen. 

De grote verscheidenheid aan algoritmen voor werkindeling maakt het 
noodzakelijk dat we er één kunnen uitkiezen. Analytische methoden maken ge- 
bruik van een wiskundige theorie om het prestatievermogen van een algoritme te 
bepalen. Simulatiemethoden bepalen het prestatievermogen door het algoritme 
voor werkindeling te imiteren met gebruikmaking van een ’representatieve’ steek- 
proef uit de processen en door het berekenen van het daaruit resulterende pres- 
tatievermogen. 


Opgaven 


4.1 Beschrijf de verschillen tussen werkindeling op korte, middellange en 
lange termijn. 


4.2 Wat is het voordeel van verschillende quantum-grootten op verschillende 
niveaus van een systeem met wachtrijen met meerdere niveaus? 


4.3 Leg de werking uit van werkindeling met meerdere niveaus. 


4.4 Noem een paar beslissingen inzake werkindeling die moeten worden ge- 
nomen boven het niveau van CVE-werkindeling. 


4.5 Welke van de volgende algoritmen zijn redelijke algoritmen voor werkin- 
deling op lange termijn en welke zijn redelijke algoritmen voor werkin- 
deling op korte termijn? 

Wie-het-Eerst-Komt-het-Eerst-Maalt 

. Bij toerbeurt 

Kortste-Job-Eerst 

Hoogste-Prioriteit-Eerst 

Langste-Job-Eerst 

Wie-het-Laatst-Komt-het-Eerst-Maalt 


moaogp 
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4.6 Stel dat u de volgende jobs moet uitvoeren op één processor: 


4.7 


48 


Job Duur van de actie Prioriteit 
1 10 3 
2 l l 
3 2 3 
4 l 4 
5 5 ie 


Stel dat de jobs zijn aangekomen in de volgorde 1, 2, 3, 4, 5. 


a. 


C. 


d. 


Maak een Gantt chart die de uitvoering van deze jobs laat zien als 
gebruik wordt gemaakt van Wie-het-Eerst-Komt-het-Eerst-Maalt, 
’bij toerbeurt’ (quantum = 1), Kortste-Job-Eerst en een algoritme 
voor werkindeling zonder voortijdige onderbreking dat op prioriteit 
gebaseerd is. 


. Wat is de turnaround-tijd van elke job voor elk van de voorgaande 


algoritmen voor werkindeling? 

Wat is de wachttijd van elke job voor elk van de voorgaande algorit- 
men voor werkindeling? 

Wat is de werkindeling met de kleinste gemiddelde wachttijd (gere- 
kend over alle jobs)? 


Definieer het verschil tussen werkindeling met en zonder voortijdige on- 
derbreking. Verklaar waarom werkindeling zonder enige vorm van voor- 
tijdige onderbreking in een computercentrum waarschijnlijk niet ge- 
bruikt zal worden. 


Stel dat de volgende jobs voor verwerking aankomen op de aangegeven 
tijden. Iedere job zal de vermelde hoeveelheid tijd draaien. Wat is de 
gemiddelde turnaround-tijd voor deze jobs? Gebruik werkindeling zon- 
der voortijdige onderbreking en baseer alle beslissingen op de informatie 
die u heeft op het tijdstip dat de beslissing moet worden gemaakt. 


oop 


Job Aankomsttijd Duur van de actie 
l 0,0 8 
2 0,4 4 
3 1,0 1 
WEKEM 


. Kortste-Job-Eerst 


Kortste-Job-Eerst wordt geacht het prestatievermogen te verbeteren, 
maar let wel dat we job 1 op tijdstip 0 hebben uitgekozen om te 
draaien, omdat we niet wisten dat weldra twee kortere jobs zouden 
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4.9 


4.10 


4.11 


4.12 


aankomen. Bereken de gemiddelde turnaround-tijd als de CVE de 
eerste tijdseenheid zonder werk wordt gelaten en dan de werkindeling 
volgens Kortste-Job-Eerst wordt gebruikt. Denk er aan dat job 1 en 
job 2 gedurende deze tijd dat er niets gedaan wordt staan te wachten, 
zodat hun wachttijd kan oplopen. Dit algoritme zou bekend kunnen 
staan als Kennis-Vooraf-werkindeling. 


Neem een algoritme voor werkindeling bij toerbeurt waarbij de ingangen 

in de gereed-wachtrij wijzers zijn naar de procesbesturingsblokken. 

a. Wat is het effect van het in de gereed-wachtrij aanbrengen van twee 
wijzers naar hetzelfde proces? 

b. Wat zijn de voor- en nadelen zijn van deze opzet? 

c. Hoe zou u het algoritme voor werkindeling bij toerbeurt wijzigen om 
hetzelfde effect teweeg te brengen zonder de dubbele wijzers? 


Stel een vergelijking op die het verband aangeeft tussen de volgende drie 
tijden voor een job. 

a. Turnaround-tijd 

b. CVE-werktijd 

c. Wachttijd 


Veel algoritmen voor CVE-werkindeling werken met parameters. Bij- 
voorbeeld, het algoritme voor werkindeling bij toerbeurt heeft een pa- 
rameter nodig die het tijdschijfje aangeeft. Wachtrijen met meerdere 
niveaus hebben een parameter nodig voor het definiëren van het aan- 
tal niveaus, het algoritme voor werkindeling op elk niveau, en de criteria 
die gehanteerd moeten worden voor het verhuizen van jobs van het ene 
niveau naar het andere, enzovoort. | 

_ Dit betekent dat deze algoritmen in feite verzamelingen van algo- 
ritmen zijn (bijvoorbeeld, de verzameling van algoritmen voor werkin- 
deling bij toerbeurt voor alle tijdschijfjes, enzovoort). Het kan zijn dat 
de ene verzameling een andere omvat (bijvoorbeeld, WEKEM is ’bij 
toerbeurt’ met een oneindig groot tijd-quantum). Welk verband bestaat 
er (zo er al een verband bestaat) tussen de volgende verzamelingenparen 
van algoritmen? 
a. Prioriteit, Kortste-Job-Eerst. 
b. Wachtrijen met meerdere niveaus en terugkoppeling, WEKEM. 
c. Prioriteit, WEKEM. 
d. Bij toerbeurt, Kortste-Job-Eerst. 


Kleinrock heeft een algoritme voor werkindeling met voortijdige onder- 
breking gebaseerd op prioriteit beschreven dat berust op het dynamisch 
veranderen van prioriteiten. Hoe groter het prioriteitsgetal, hoe hoger de 
prioriteit. Wanneer een job op de CVE staat te wachten (in de gereed- 
wachtrij, maar niet in uitvoering), verandert zijn prioriteit met snelheid 
a; wanneer de job in uitvoering is, verandert zijn prioriteit met snelheid 
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B. Alle processen krijgen een prioriteit 0 wanneer zij de gereed-wachtrij 
binnenkomen. De parameters «a en B kunnen zó gekozen worden dat ze 
tal van verschillende algoritmen voor werkindeling geven. 

a. Wat is het algoritme als gevolg van B > a > 0? 

b. Wat is het algoritme als gevolg van a < B < 0? 


4.13 Een algoritme voor CVE-werkindeling bepaalt een volgorde waarin de 
ingedeelde jobs worden uitgevoerd. Gegeven is dat n jobs moeten wor- 
den ingedeeld op één processor, hoeveel verschillende indelingen zijn er? 
Geef een formule uitgedrukt in n. 


4.14 Stel dat een algoritme voor werkindeling (op het niveau van CVE- 
werkindeling op korte termijn) die programma’s bevoordeelt die in het 
recente verleden weinig processortijd hebben gebruikt. Waarom zal dit 
algoritme I/O-gebonden programma’s bevoordelen en toch niet CVE- 
gebonden programma’s permanent uithongeren? 


4.15 Verklaar de verschillen in de mate waarin de volgende algoritmen voor 
werkindeling discrimineren ten gunste van korte jobs. 
a. Wie-het-Eerst-Komt-het-Eerst-Maalt. 
b. Bij toerbeurt. 
c. Wachtrijen met meerdere niveaus en terugkoppeling. 


4.16 Bepaal het verschil tussen (1) een algoritme voor werkindeling met 
wachtrijen met meerdere niveaus en terugkoppeling, en (2) een algoritme 
voor CVE-werkindeling met meerdere wachtrijen (voorgrond/achter- 
grond) dat indeelt bij toerbeurt voor de voorgrond en voortijdig onder- 
breekt op grond van prioriteit voor de achtergrond. 
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GEHEUGENBEHEER 


In hoofdstuk 4 lieten we zien hoe de CVE gemeenschappelijk kan worden ge- 
bruikt door een verzameling van processen. Als gevolg van CVE-werkindeling 
kunnen we zowel de gebruiksfactor van de CVE als de snelheid waarmee de com- 
puter respons geeft aan zijn gebruikers verbeteren. Om evenwel deze verbetering 
in het prestatievermogen te realiseren, moeten we diverse processen in het geheu- 
gen houden; we moeten gemeenschappelijk gebruik van het geheugen toestaan. 

In dit hoofdstuk bespreken we verschillende manieren om het geheugen te 
beheren. De algoritmen voor geheugenbeheer lopen uiteen van een primitieve 
kale-machine-benadering tot paginerings- en segmenteringsstrategieën. Iedere 
benadering heeft zijn eigen voor- en nadelen. 


5.1 Opmerkingen vooraf 
Het geheugen staat centraal in de werking van een modern computersysteem. 


Zoals aangegeven in figuur 5.1, staan zowel de CVE als het I/O-systeem in wissel- 
werking met het geheugen. Het reheugen is een lange reeks woorden en bytes, 


1/O- 
systeem 


geheugen 


Figuur 5.1 | 
Centrale aard van het geheugen in een computersysteem 
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elk met zijn eigen adres. De wisselwerking wordt bewerkstelligd door een serie 
lees- of schrijfbewerkingen naar specifieke geheugenadressen. De CVE haalt op 
uit en bergt weg in het geheugen. 

In de meeste gevallen doorloopt een gebruikersprogramma diverse stappen 
voordat het wordt uitgevoerd (zie figuur 5.2). Adressen kunnen gedurende deze 
stappen op verschillende manieren worden gerepresenteerd. Adressen in het 
bronprogramma zijn in het algemeen symbolisch (zoals x). Het is kenmerkend 
voor een compileerprogramma dat dit deze symbolische adressen zal omzetten in 
verplaatsbare adressen (zoals 14 bytes vanaf het begin van deze module). Het 
montageprogramma (linkage editor) of laadprogramma (loader) zal op zijn beurt 
deze verplaatsbare adressen omzetten in absolute adressen (zoals 74014). Dit om- 
zetten is het koppelen van de ene adresruimte aan een andere. 

Een programma moet uiteindelijk worden gekoppeld aan absolute adressen 
en in het geheugen worden geladen om te worden uitgevoerd. Tijdens de uitvoe- 
ring heeft het programma toegang tot instructies en gegevens in het geheugen 
door het genereren van deze absolute adressen. Tenslotte wordt het programma 
beëindigd; zijn geheugenruimte wordt beschikbaar gesteld en het volgende pro- 
gramma kan worden geladen en uitgevoerd. 

Een typische instructie-uitvoeringscyclus bijvoorbeeld haalt eerst een in- 
structie uit het geheugen. De instructie wordt gedecodeerd, waarbij mogelijk 
operanden uit het geheugen moeten worden opgehaald. Na het uitvoeren van de 
instructie op de operanden is het mogelijk dat resultaten weer in het geheugen 
moeten worden opgeborgen. Let erop dat de geheugeneenheid alleen een stroom 
van geheugenadressen ziet; hij weet niet hoe deze worden gegenereerd (de pro- 
grammateller, indicering, indirecte adressen, adressen in de vorm van lettersym- 
bolen, enzovoort) of waarvoor deze dienen (instructies of gegevens). Daarom 
kunnen we buiten beschouwing laten hoe een geheugenadres door een program- 
ma wordt gegenereerd; het programma kan elke gewenste programmatechniek 
gebruiken om zijn adressen te genereren. Wij zijn alleen geïnteresseerd in de volg- 
orde van de geheugenadressen die door het in uitvoering zijnde programma wor- 
den gegenereerd. 

In dit hoofdstuk bestuderen we tal van verschillende methoden voor geheu- 
genbeheer. Deze methoden weerspiegelen diverse benaderingen, waarbij de effec- 
tiviteit van de verschillende algoritmen afhangt van de specifieke situatie. Het 
kiezen van een methode voor geheugenbeheer voor een bepaald systeem hangt 
van veel factoren af, maar speciaal van het ontwerp van de apparatuur van het 
systeem. Ieder algoritme heeft zijn eigen eisen voor ondersteuning door de ap- 
paratuur. We beginnen met de minst complexe apparatuur en gaan vandaar lang- 
zaam naar methoden die complexer en geavanceerder zijn. 


5.2 Kale machine 


Verreweg de simpelste methode voor geheugenbeheer is geen methode. De gebrui- 
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Figuur 5.2 
Verwerking van een gebruikersprogramma in meerdere stappen 


5.2 Kale machine 


ker krijgt de kale machine en heeft volledig de beschikking over de gehele geheu- 
genruimte (zie figuur 5.3). 

Deze benadering heeft enkele duidelijke voordelen. Het geeft de gebruiker 
maximale flexibiliteit; de gebruiker kan over het gebruik van het geheugen be- 
schikken zoals hij wil. Dit betekent maximale eenvoud en minimale kosten. Er is 
geen speciale apparatuur nodig voor deze benadering van geheugenbeheer. Ook 
is er geen besturingssysteem-programmatuur nodig. 

Dit systeem heeft ook zijn beperkingen: het geeft geen dienstverlening. De 
gebruiker heeft volledig de beschikking over de computer, maar het besturings- 
systeem heeft niet de besturing over onderbrekingen, geen residente monitor voor 
het verwerken van systeemaanroepen of fouten, en geen ruimte om te voorzien 
in het achtereenvolgens verwerken van besturingskaarten of jobs. Vandaar dat 
de kale-machine-benadering zijn beperkingen heeft. In het algemeen wordt deze 
alleen gebruikt op systemen voor speciale toepassingen, waar de gebruikers flexi- 
biliteit en eenvoud vereisen en bereid zijn hun eigen functieroutines te program- 
meren. 


gebruiker 


36K 


Figuur 5.3 
Kale machine 
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5,3 Residente monitor 


De op één na eenvoudigste methode bestaat hierin dat het geheugen in twee delen 
wordt verdeeld, één voor de gebruiker en één voor de residente monitor van het 
besturingssysteem (zie figuur 5.4). Het is mogelijk de residente monitor in ofwel 
het lage of het hoge gedeelte van het geheugen te plaatsen. De hoofdfactor die 
op deze beslissing van invloed is, is in het algemeen de plaats van de onder- 
brekingsvector. Aangezien de onderbrekingsvector zich dikwijls in het lage ge- 
deelte van het geheugen bevindt, is het het meest gebruikelijk de residente mo- 
nitor in het lage deel van het geheugen te plaatsen. Dus zullen we alleen de situa- 
tie bespreken dat de monitor zich in het lage gedeelte van het geheugen bevindt; 
de ontwikkeling van de andere situatie gaat net zo. 

Deze aanpak werd gebruikt in het FORTRAN Monitoring System voor de 
7094, een van de eerste ’besturingssystemen’. Dit is hoofdzakelijk de benaderings- 
wijze in veel huidige microcomputersystemen, zoals CP/M. 


5,3.1 Apparatuur ter beveiliging 


Als de monitor zich in het lage gedeelte van het geheugen bevindt en een gebrui- 


monitor 


hekregister - 


gebruiker 


Figuur 5.4 
Residente monitor 
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kersprogramma wordt uitgevoerd in het hoge gedeelte, moeten we de monitor- 
code en -gegevens beveiligen tegen wijzigingen veroorzaakt (per ongeluk of met 
opzet) door het gebruikersprogramma. Deze beveiliging moet worden geleverd 
door de apparatuur en kan op verschillende manieren worden geïmplementeerd. 
De algemene benadering is aangegeven in figuur 5.5. Elk adres (instructie of 
gegevens) dat door het gebruikersprogramma wordt gegenereerd, wordt verge- 
leken met een hekadres. Is het gegenereerde adres groter dan of gelijk aan het 
hekadres, dan is het een legale verwijzing naar het gebruikersgeheugen en wordt 
het op de gebruikelijke wijze doorgestuurd naar de geheugeneenheid. Is het ge- 
genereerde adres echter kleiner dan het hekadres, dan is het adres een illegale 
verwijzing naar het monitorgeheugen. De verwijzing wordt onderschept en er 
wordt een ’val’ naar het besturingssysteem gegenereerd (adresseringsfout). Het 
besturingssysteem neemt dan de juiste maatregel (gewoonlijk beëindiging van het 
programma met een passende foutmelding en geheugendump). 

Let erop dat iedere verwijzing naar het geheugen door het gebruikerspro- 
gramma moet worden gecontroleerd. In het algemeen zal deze controle iedere 
geheugentoegang vertragen met de tijd die nodig is voor de vergelijking, zodat 
een geheugenverwijzing 995 nanoseconden kan duren in plaats van 980 nanose- 
conden. Een voorzichtig circuit-ontwerp kan dit vergelijken vaak met andere ac- 
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Figuur 5.5 
Adresbeveiliging door de apparatuur voor een residente monitor 
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tiviteiten overlappen om de effectieve toegangstijd te bekorten. 

Het besturingssysteem, draaiend in de monitor-modus, heeft in het alge- 
meen onbeperkte toegang tot zowel het monitor- als het gebruikersgeheugen. De- - 
ze voorziening biedt het besturingssysteem de mogelijkheid gebruikersprogram- 
ma’s in het geheugen te laden, een geheugendump te maken in geval van fouten, 
toegang te hebben tot parameters van systéemaanroepen en deze te wijzigen, 
enzovoort. 

Computersystemen verschillen aanzienlijk in de manier waarop het hek- 
register is gespecificeerd. Eén benadering bestaat uit het inbouwen ervan in de 
apparatuur als een vaste constante. Op de HP 2116B computer bijvoorbeeld was 
het fundamentele binaire laadprogramma opgeslagen op de geheugenplaatsen 
77700 tot 77777 (het hoge gedeelte van het geheugen op een machine met 32K 
woorden). Tijdens de uitvoering van een gebruikersprogramma was het niet mo- 
gelijk een geheugenpositie boven positie 77700 te adresseren; de waarde van het 
hekadres was in de apparatuur ingebouwd. 

De moeilijkheid met een vast hekadres dat door de apparatuur wordt gele- 
verd is het selecteren van een juist adres. Als het adres te klein is, is de monitor 
niet geheel beveiligd; als het adres te groot is, is geheugen dat de monitor niet 
nodig heeft beveiligd en dus niet beschikbaar voor de gebruiker. Wat het pro- 
bleem ernstiger maakt is het feit dat de monitor, zoals alle programmatuur, met- 
tertijd verandert en groter of kleiner wordt. Vandaar dat het hekadres dat van- 
daag ’juist’ is morgen misschien niet juist is. 

Voor de oplossing van dit probleem wordt gewoonlijk een hekregister ge- 
bruikt. Het hekregister bevat het adres van het hek en wordt gebruikt om de 
juistheid van alle geheugenverwijzingen door de gebruiker te controleren. Het 
kan door het besturingssysteem worden geladen met gebruikmaking van een spe- 
ciale bevoorrechte instructie. Het hekregister kan alleen door een programma 
worden geladen dat draait in de monitor-modus. Deze opzet biedt de monitor de 
mogelijkheid de waarde van het hekregister te wijzigen op elk moment dat de 
grootte van de monitor verandert. 


5.3.2 Verplaatsing 


Een ander probleem dat we moeten bekijken is het laden van gebruikersprogram- 
ma’s. Hoewel de adresruimte van de computer begint bij 000000, is het eerste 
adres van het gebruikersprogramma niet 000000, maar het eerste adres voorbij 
het hek. Deze regeling kan van invloed zijn op de adressen die het gebruikerspro- 
gramma gebruikt. Gewoontegetrouw kan de koppeling van instructies en gege- 
vens aan geheugenadressen plaatsvinden tijdens het vertalen of het laden van het 
programma. Als het hekadres bij het vertalen bekend is, kan absolute code wor- 
den gegenereerd. Deze code zal beginnen bij het hek en zich vandaaruit uitstrek- 
ken. Als het hekadres evenwel daarna verandert, is het noodzakelijk deze code 
opnieuw te vertalen. Een alternatief zou zijn dat het vertaalprogramma verplaats- 
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bare code genereert. In dit geval wordt de koppeling uitgesteld tot het tijdstip 
van het laden van het programma. Als het hekadres verandert, hoeft de gebrui- 
kerscode alleen opnieuw te worden geladen om deze veranderde waarde in zich 
op te nemen. 

In beide gevallen echter moet het hek gedurende de uitvoering van het pro- 
gramma statisch zijn. Het is duidelijk dat, als de adressen van de gebruiker met 
behulp van het hek gekoppeld zijn aan fysieke adressen, deze adressen dan ongel- 
dig zullen zijn als het hek verandert. Dus kan het hek alleen worden verschoven 
wanneer er geen gebruikersprogramma in uitvoering is. Er zijn evenwel gevallen 
waarin het wenselijk is tijdens de uitvoering van een programma de grootte van 
de monitor (en dus de positie van het hek) te wijzigen. Bijvoorbeeld, de monitor 
bevat code en bufferruimte voor stuurprogramma’s voor de randapparatuur. 
Wordt een stuurprogramma (of andere besturingssysteem-functie) niet voort- 
durend gebruikt, dan is het niet wenselijk die code en gegevens in het geheugen 
te houden, omdat we die ruimte wellicht voor andere doeleinden zullen kunnen 
gebruiken. Zulke code wordt soms tijdelijke (Engels: transient) monitorcode ge- 
noemd; deze komt en gaat, al naar behoefte. Zo verandert het gebruik maken 
van deze code de grootte van de monitor tijdens programma-uitvoering. 

Er zijn twee manieren om de basisopzet, die we hebben gegeven voor de 
dynamische verandering van de monitorgrootte, te wijzigen. Vroeger maakte een 
PDP-11 besturingssysteem gebruik van de benaderingswijze die is aangegeven in 
figuur 5.6. De gebruiker werd in het hoge gedeelte van het geheugen geladen, 
naar beneden in de richting van het hek, en niet vanaf het hek omhoog in de 
richting van het hoge geheugengedeelte. Het voordeel hiervan is dat alle onge- 
bruikte ruimte zich in het midden bevindt en óf de gebruiker óf de monitor, al 
naar behoefte, zich in dit ongebruikte geheugen kan uitbreiden. 

Een algemenere aanpak, gebruikt op de CDC 6600 computers, bestaat hier- 
in dat de adreskoppeling wordt uitgesteld tot het tijdstip van uitvoering. Deze 
opzet voor dynamische verplaatsing vereist een enigszins andere ondersteuning 
door de apparatuur, zoals weergegeven in figuur 5.7. Het hekregister wordt nu 
een verplaatsings- of basisregister genoemd. De waarde in het basisregister wordt 
bij elk adres dat door een gebruikersproces wordt gegenereerd opgeteld op het 
tijdstip dat dit adres naar het geheugen gestuurd wordt. Bijvoorbeeld, als het hek 
op 1400 gezet is, dan wordt een poging van de gebruiker om adrespositie 0 te 
adresseren dynamisch verplaatst naar positie 1400; een toegang tot adres 346 
wordt verplaatst naar positie 1746. 

Let erop dat de gebruiker nooit het werkelijke fysieke adres ziet. De gebrui- 
ker kan een wijzer naar positie 346 opzetten, deze in het geheugen opslaan, ermee 
werken, deze vergelijken met andere adressen — voortdurend als het getal 346. 
Alleen wanneer dit adres wordt gebruikt als een geheugenadres (in een indirecte 
laad- of opbergbewerking misschien) vindt verplaatsing met betrekking tot het 
basisregister plaats. Het gebruikersprogramma werkt met logische adressen. De 
apparatuur die zorgdraagt voor de geheugenkoppeling zet de logische adressen 
om in fysieke adressen. 


156 Hoofdstuk 5 Geheugenbeheer 


hekregister 


gebruiker 


65K 


Figuur 5.6 
De gebruiker wordt in het hoge gedeelte van het geheugen geladen 


Voor deze apparatuur is voor een verandering in de waarde van het hek- 
register alleen nodig dat het basisregister veranderd wordt; het gehele gebruikers- 
geheugen wordt dan verschoven naar de juiste posities met betrekking tot de nieu- 
we hekwaarde. Al maakt dit ontwerp het noodzakelijk dat een aanzienlijke hoe- 
veelheid geheugen wordt gekopieerd, het biedt de mogelijkheid dat de hekwaarde 
op elk willekeurig moment wordt gewijzigd. 

Merk ook op dat we nu twee verschillende soorten adressen hebben: logi- 
sche adressen (op het interval 0 tot max) en fysieke adressen (op het interval 
R+0 tot R+ max voor een hekwaarde R). De gebruiker genereert alleen logische 
adressen en denkt dat het programma draait in de posities 0 tot max. 

Het besturingssysteem weet wel beter en kan het fysieke geheugen recht- 
streeks adresseren in de monitor-modus. Alle informatie die vanuit het gebrui- 
kersprogramma aan het besturingssysteem wordt doorgegeven (zoals buffer- 
adressen in systeemaanroepen) moet expliciet door de programmatuur van het 
besturingssysteem worden verplaatst voordat deze wordt gebruikt. Deze nood- 
zaak geldt in het bijzonder voor de adressen die worden doorgegeven aan de 
randapparatuur. De gebruiker levert logische adressen; deze logische adressen 
moeten, voordat deze worden gebruikt, worden gekoppeld aan fysieke adressen. 

Het begrip logische adresruimte, die wordt gekoppeld aan een afzonderlijke 

fysieke adresruimte, staat centraal in een goed geheugenbeheer. 
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Figuur 5.7 
Dynamische verplaatsing met gebruikmaking van een verplaatsingsregister 
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De opzet van het geheugenbeheer door de residente monitor lijkt misschien van 
weinig nut omdat deze inherent gebaseerd blijkt op één gebruiker. Het was echter 
het basisontwerp zoals dat gebruikt werd in twee systemen met tijddeling uit 
de beginperiode: het CTSS en het Q-32 systeem. Deze systemen gebruikten een 
residente monitor, waarbij de rest van het geheugen beschikbaar was voor de op 
dat moment draaiende gebruiker. 

Wanneer deze systemen naar de volgende gebruiker omschakelden, werd 
de momentele inhoud van het gebruikersgeheugen weggeschreven naar een extern 
geheugen (een schijf of een trommel), en werd het geheugen van de volgende 
gebruiker ingelezen. Deze methode noemt men programmaverwisseling (Engels: ` 
swapping; zie figuur 5.8). 


5.4.1 Extern geheugen 
Voor programmaverwisseling is een extern geheugen vereist. Gewoonlijk is het 


externe geheugen een snelle trommel of een schijf. Dit moet groot genoeg zijn 
om kopieën te kunnen bergen van alle geheugenbeelden voor alle gebruikers en 
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Figuur 5.8 
Programmaverwisseling van twee gebruikers met een trommel als extern geheugen 


moet directe toegang bieden tot deze geheugenbeelden. De gereed-wachtrij be- 
staat uit alle processen waarvan de geheugenbeelden op het externe geheugen 
staan en die gereed zijn voor uitvoering. Een aparte systeemvariabele geeft aan 
welk proces momenteel in het geheugen is. Wanneer het programma voor CVE- 
werkindeling besluit een proces uit te voeren, roept dit het verdeelprogramma 
aan. Het verdeelprogramma controleert of dat proces in het geheugen staat; zo 
niet, dan zet het verdeelprogramma het proces dat nu in het geheugen staat uit 
het geheugen en haalt het het gewenste proces binnen in het geheugen. Dan laadt 
het de registers zoals gebruikelijk en geeft het de besturing over aan het geselec- 
teerde proces. 


5.4.2 Tijd nodig voor programmaverwisseling 


Het moet duidelijk zijn dat de contextomschakelingstijd in zo’n systeem met 
programmaverwisseling tamelijk hoog is. Laten we, om een indruk te krijgen van 
de contextomschakelingstijd, eens aannemen dat het gebruikersprogramma 20K 
woorden groot is en het externe geheugen een trommel is met vaste lees/ schrijf- 
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koppen met een gemiddelde wachttijd van 8 milliseconden en een gegevensover- 
drachttijd van 250.000 woorden per seconde. Dan duurt een overbrenging van 
het programma van 20K woorden naar of uit het geheugen: 


8 msec + (20K woorden / 250.000 woorden/sec) = 8 msec + (2/25) sec 
= 8 msec + (2000/25) msec 
= 88 msec 


Aangezien we zowel uit als naar het geheugen moeten overbrengen, is de totale 
tijd nodig voor programmaverwisseling ongeveer 176 milliseconden. 

In het Q-32 systeem met tijddeling werd een trommel met een gemiddelde 
wachttijd van 10 milliseconden en een gegevensoverdrachtsnelheid van 363.000 
woorden per seconde gebruikt, hetgeen resulteerde in een gemiddelde tijd nodig 
voor programmaverwisseling van 130 milliseconden voor 20K woorden. 

Voor een efficiënt CVE-gebruik willen we dat onze uitvoeringstijd voor elk 
proces lang is in verhouding tot de tijd nodig voor programmaverwisseling. Zo 
moet bijvoorbeeld in een algoritme voor CVE-werkindeling bij toerbeurt het tijd- 
quantum aanmerkelijk groter zijn dan 0,176 seconden. 

Let erop dat het grootste deel van de tijd nodig voor programmaverwis- 
seling de tijd is die nodig is voor het overbrengen van gegevens. De totale ge- 
gevensoverdrachttijd is recht evenredig met de hoeveelheid geheugen die verwis- 
seld moet worden. Als we een computersysteem van 32K hebben, met een re- 
sidente monitor van 12K, is het grootst mogelijke gebruikersprogramma 20K. 
Veel gebruikersprogramma’s kunnen echter veel kleiner zijn, zeg 4K. Een pro- 
gramma van 4K zou kunnen worden verwisseld en uit het geheugen gezet in 
slechts 24 milliseconden, vergeleken met de 88 milliseconden voor het uit het 
geheugen brengen van 20K. Daarom zou het nuttig zijn om precies te weten 
hoeveel geheugen een gebruikersprogramma in gebruik heeft, niet alleen hoeveel 
het zou kunnen gebruiken. Dan zouden we aleen dat gedeelte hoeven te verwis- 
selen dat werkelijk gebruikt wordt, waardoor de tijd nodig voor programmaver- 
wisseling wordt teruggebracht. Wil deze opzet werken, dan moet de gebruiker de 
monitor op de hoogte houden van mogelijke veranderingen in geheugeneisen. 
Daarom zal een programma met dynamische geheugeneisen systeemaanroepen 
dienen te doen (Vraag geheugen aan/Geef geheugen vrij) om de monitor op de 
hoogte te houden van zijn zich wijzigende geheugenbehoeften. _ 

De effectiviteit van programmaverwisseling kan ook worden verbeterd door 
het prestatievermogen van het externe geheugen te verhogen. Neem bijvoorbeeld 
het Grote Kernengeheugen (Large Core Storage; LCS) van IBM, en het Uitge- 
breide Kernengeheugen (Extended Core Storage; ECS) van CDC. LCS heeft een 
toegangstijd van 8 microseconden en een overbrengingssnelheid van 400.000 
woorden per seconde. Met LCS duurt het slechts 100 milliseconden om 20K uit 
en naar het geheugen te brengen. ECS heeft een toegangstijd van 3 microsecon- 
den en een overbrengingstijd van 10.000.000 woorden per seconde. De totale tijd 
nodig voor programmaverwisseling voor 20K woorden is dus slechts 4 millisecon- 
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den. Nieuwe massageheugens, massa-halfgeleiders en bellengeheugens maken on- 
geveer even snelle verwisselingen vanuit het interne geheugen naar het externe 
geheugen mogelijk. 


54.3 Overlappende programmaverwisseling 


Het effect van programmaverwisseling op de contextomschakelingstijd kan ver- 
der worden teruggebracht door programmaverwisseling en -uitvoering elkaar te 
laten overlappen. Kijk naar het schema dat figuur 5.9 laat zien. Het doel is de 
programmaverwisseling van het ene proces te laten overlappen met de uitvoering 
van een ander. Dan zal de CVE niet zonder werk zitten terwijl de programmaver- 
wisseling plaatsvindt. Terwijl het ene gebruikersprogramma wordt uitgevoerd, 
wordt het voorgaande gebruikersprogramma uit het geheugen gehaald uit buffer 
1, en het volgende programma dat moet worden uitgevoerd wordt al in het geheu- 
gen gebracht in buffer 2. 3 

Let er evenwel op dat, wanneer het huidige gebruikersprogramma de CVE 
vrijgeeft, we het volgende gebruikersprogramma moeten verplaatsen van buffer 
2 naar de gebruikersregio voordat het kan worden uitgevoerd. Het programma 
dat momenteel in de gebruikersregio zit moet ook naar één van de buffers voor 


monitor- 
te 
OR ae +. 
huidige 
gebruiker 
Figuur 5.9 


Overlappende programmaverwisseling 
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programmaverwisseling worden verplaatst. Zou dit niet worden gedaan, dan zou- 
den we alleen het programma in buffer 2 kunnen uitvoeren door het hek te ver- 
schuiven, zoals figuur 5.10 laat zien. Het vorige gebruikersprogramma (in de ge- 
bruikersregio) wordt dan blootgesteld aan onjuiste wijziging door het programma 
in buffer 2. Daarom moeten we een programmaverwisseling binnen het geheugen 
doen. 

Deze aanpak is ook wat beperkt als werkelijk zeer snelle randapparatuur 
voor programmaverwisseling wordt gebruikt. ECS bijvoorbeeld heeft een over- 
drachtssnelheid die gelijk is aan de snelheid van het interne geheugen. Wanneer 
ECS aan de overdracht bezig is, zijn er geen geheugencycli meer over voor ge- 
bruik door de CVE. Zo wordt de CVE-werking volledig stopgezet wanneer ECS 
wordt gebruikt, en overlapping van CVE en programmaverwisseling is dan niet 
mogelijk. 

Er gelden ook nog andere beperkingen voor programmaverwisseling. Als 
we een proces willen verwisselen, moeten we er zeker van zijn dat dit volledig 
stilstaat. Een belangrijk punt van zorg is I/O die nog gaande is. Als een proces 
nog wacht op een I/O-bewerking, zou het kunnen zijn dat we het proces willen 
verwisselen om zijn geheugen vrij te maken. Wanneer echter de I/O het gebrui- 
kersgeheugen voor de I/O-buffers asynchroon adresseert, kan het proces niet 


buffer 1 


hekregister 


vorige 
gebruiker 


Figuur 5.10 
We kunnen proberen de uitvoering van een programma mogelijk te maken door het hek te 
verschuiven 
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worden verwisseld. Stel dat de I/O-bewerking in een wachtrij werd gezet omdat 
het randapparaat bezig was. Als we proces | uit het geheugen zetten en proces 2 
binnenbrengen, kan de I/O-bewerking proberen het geheugen te gebruiken dat 
nu tot proces 2 behoort. De twee hoofdoplossingen voor dit probleem zijn: (1) 
verwissel nooit een proces met uitstaande I/O, of (2) voer I/O-bewerkingen al- 
leen uit in buffers van het besturingssysteem. Overbrenging van gegevens tussen 
het besturingssysteem en het gebruikersgeheugen vindt dan alleen plaats wanneer 
het proces weer in het interne geheugen gebracht is. 


5.5 Meerdere partities 


De geheugenconfiguratie die het gevolg is van overlappende programmaverwis- 
seling is in feite dezelfde als de geheugenconfiguratie voor multiprogrammering: 
er is meer dan één programma tegelijkertijd in het geheugen. Voor multiprogram- 
mering wordt de CVE snel van het ene programma naar het andere overge- 
schakeld. Het probleem van het geheugenbeheer is het toewijzen van geheugen 
aan de vele programma’s die in de jobpot kunnen zijn om te worden uitgevoerd. 

Het geheugen is verdeeld in een aantal regio’s of partities. Iedere regio kan 
één programma hebben dat moet worden uitgevoerd. Dus is het multiprogram- 
meringsniveau begrensd door het aantal regio’s. Wanneer een regio vrij is, wordt 
een programma geselecteerd uit de job-wachtrij en in de vrije regio geladen. Wan- 
neer dit eindigt komt de regio beschikbaar voor een ander programma. 

Er zijn twee hoofdschema’s voor geheugenbeheer mogelijk. Elk van beide 
benaderingen verdeelt het geheugen in een aantal regio’s of partities. Het voor- 
naamste onderscheid tussen de twee benaderingen wordt gevormd door de vraag 
of de regio’s statisch zijn of dynamisch. Deze schema's zijn: toewijzing van meer- 
dere aaneensluitende vaste partities of toewijzing van meerdere aaneensluitende va- 
riabele partities. De twee bekendste voorbeelden van deze algoritmen zijn de ver- 
sies MFT (multiprogrammering met een vast aantal taken) en MVT (multipro- 
grammering met een variabel aantal taken) van het OS/360 besturingssysteem 
van IBM. Vanwege hun beknoptheid gebruiken we deze afkortingen om deze 
twee hoofdgroepen van algoritmen aan te duiden. 


5.5.1 Apparatuur ter beveiliging 


Zoals we in paragraaf 1.8.2 zagen, en ook in figuur 5.10, moeten we eerst een 
manier zien te vinden om de code en gegevens binnen één regio te beveiligen 
tegen programma’s in andere regio’s. Wat we nodig hebben is een mechanisme 
om de geheugenruimte te beveiligen die zich voor en achter een draaiend program- 
ma bevindt. Deze beveiliging kunnen we krijgen door het gebruiken van twee 
registers, zoals aangegeven in figuur 5.11. 

Deze twee registers leveren de boven- en ondergrens voor de adressen die 
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Figuur 5.11 
Twee grensregisters definiéren een logische adresruimte 


legaal door een gebruikersprogramma kunnen worden gegenereerd. Deze kunnen 
op twee manieren worden gedefinieerd: 


@ Grensregisters. De waarden van de kleinste en grootste fysieke adressen (bij- 
voorbeeld: ondergrens = 100040 en bovengrens = 174640). Legale gebrui- 
kersadressen lopen van de ondergrens tot de bovengrens. 

@ Basis- en limietregister. De waarde van het kleinste fysieke adres en het logisch 
adresgebied (bijvoorbeeld basis = 100040 en limiet = 74600). Legale gebrui- 
kersadressen lopen van 0 tot limiet en worden dynamisch verplaatst naar fysie- 
ke adressen die lopen van basis tot basis + limiet. 


Zoals figuur 5.12 laat zien, verschilt de apparatuur voor het gebruiken van deze 
twee registers enigszins. Grensregisters vereisen statische verplaatsing ten tijde 
van het vertalen of het laden. Elk logisch adres moet groter dan of gelijk aan de 
ondergrens en kleiner dan de bovengrens zijn. Met een basis- en limietregister 
moet ieder logisch adres kleiner zijn dan het limietregister, en wordt het dan 
dynamisch verplaatst door de waarde in het basisregister daarbij op te tellen. Dit 
verplaatste adres wordt naar het geheugen gestuurd. De CDC 6600 computer en 
zijn afstammelingen maken gebruik van een basis- en een limietregister. 
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Figuur 5.12 
(a) Grensregisters en (b) basis- en limietregister 


55.2 Vaste regio’s (MFT) 


In MFT zijn de regiogrootten vast en veranderen niet bij het draaien van het 
systeem. Bijvoorbeeld, een geheugen van 32K woorden zou in regio’s van de vol- 
gende grootte kunnen worden verdeeld: 


Residente monitor 10K 
Zeer kleine jobs 4K 
Gemiddelde jobs 6K 


Grote jobs 12K 
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Job-werkindeling in MFT 
Bij het binnenkomen van jobs in het systeem worden zij in een job-wachtrij gezet. 
Het programma voor job-werkindeling houdt rekening met de geheugeneisen van 
elke job en de beschikbare regio’s bij het bepalen welke jobs geheugen krijgen 
toegewezen. Wanneer ruimte aan een job wordt toegewezen, wordt de job geladen 
in een regio (waarbij de job zonodig verplaatst wordt). Dan kan de job om de 
CVE wedijveren. Wanneer een job eindigt, geeft deze zijn geheugenregio vrij en 
de job-werkindeler kan deze dan vullen met een andere job uit de job-wachtrij. 
Bij het aan jobs toewijzen van geheugen is een aantal variaties mogelijk. 
Eén strategie bestaat hierin dat alle jobs bij binnenkomst in het systeem worden 
geclassificeerd overeenkomstig hun geheugeneisen. Deze classificatie kan worden ` 
bereikt door van de gebruiker te verlangen dat hij de maximaal benodigde hoe- 
veelheid geheugen die nodig is opgeeft. Een andere mogelijkheid is dat het sys- 
teem de geheugeneisen automatisch probeert vast te stellen. Bijvoorbeeld, een 
eerste doorgang van de besturingskaarten kan worden gebruikt om de maximale 
geheugenbehoefte vast te stellen. Iedere geheugenregio heeft zijn eigen job-wacht- 
rij (figuur 5.13). De job-classificatie wordt gebruikt om de juiste wachtrij voor de 
job uit te kiezen. 


monitor 


3 
ž 
3 
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Figuur 5.13 | 
MFT met afzonderlijke wachtrijen voor elke regio 
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Als we bijvoorbeeld drie gebruikersgeheugenregio’s hebben, ter grootte van 
2K, 6K en 12K, hebben we drie wachtrijen nodig: W2, W6 en W12. Een binnen- 
komende job die 5K geheugen nodig heeft wordt dan achteraan in wachtrij W6 
gezet; een nieuwe job die 10K nodig heeft wordt in W12 geplaatst; een job van 
2K gaat naar W2. Werkindeling vindt voor elke wachtrij afzonderlijk plaats. Om- 
dat elke wachtrij zijn eigen geheugenregio heeft, is er geen wedijver tussen de 
wachtrijen om geheugen. 

Een andere benadering is alle jobs in één wachtrij te gooien (zie figuur 
5.14). Het programma voor job-werkindeling selecteert de volgende job die moet 
worden uitgevoerd en wacht tot er een geheugenregio van die grootte beschikbaar 
is. Stel dat we een WEKEM job-werkindeler hadden, met de job-wachtrij van 
figuur 5.14 en regio’s van 2K, 6K en 12K. We zouden eerst de regio van 6K 
toewijzen aan job 1 en de regio van 2K aan job 2. Aangezien onze volgende job 
3K vereist, hebben we de regio van 6K nodig. Omdat de regio van 6K door job 
1 wordt gebruikt, moeten we wachten tot job 1 klaar is; dan wordt de regio van 
6K aan job 3 toegewezen. Job 4 moet wachten tot job 3 wordt geselecteerd (om- 
dat onze job-werkindeler volgens WEKEM werkt), zelfs al is de regio voor job 4 
vrij. 


…… [ak | 1k | 7K | 7K | 3k | 2k | 5k |W st 


12K 


Figuur 5.14 
MFT met een gemeenschappelijke wachtrij 
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Een meteen voor de hand liggende variant op dit schema zal proberen te 
voorkomen dat de geheugenregio’s zonder werk zitten. Dus wanneer een regio 
beschikbaar komt, slaan we jobs in de job-wachtrij over om de eerste job te vinden 
die in die regio past. We selecteren deze job, zelfs als jobs van hogere prioriteit 
(maar groter) daarvóór in de job-wachtrij staan te wachten. Deze jobs met hogere 
prioriteit kunnen de beschikbare regio niet gebruiken, daar ze te groot zijn. Dus 
belemmeren we ze niet in hun voortgang door een kleinere job (maar met lagere 
prioriteit) te starten. 

Een andere variant gaat uit van de volgende vraag: waarom laten we job 3 
wachten terwijl er een regio zonder werk is die groot genoeg is om job 3 in te 
draaien? We kunnen job 3 klaarblijkelijk indelen in de regio van 12K. Het is 
waar dat job 3 zou kunnen draaien in de regio van 6K, maar deze regio is toevallig 
bezet. Moeten we nu job 3 indelen in de regio van 12K (en ruimte verspillen) of 
moet deze job wachten terwijl job 4, die een lagere prioriteit heeft (en die uitslui- 
tend kan draaien in de regio van 12K), wordt ingedeeld? Als we besluiten job 4 
te draaien, waardoor job 3 moet wachten, wat doen we dan wanneer job 4 ein- 
digt? Laten we de regio van 12K zonder werk zitten (gereserveerd voor een grote 
job die kan komen), of gebruiken we deze voor een of andere job die in een 
kleinere regio zou kunnen draaien? 

Deze beslissingen komen overeen met de keuze tussen een geheugentoe- 
wijzingsbeleid van uitsluitend-best-passende of best-passende-beschikbare regio. 

Nog weer een andere variatie op MFT ontstaat door er programmaverwis- 
seling aan toe te voegen. Als we diverse jobs hebben die allemaal in een gegeven 
regio passen, kunnen we programmaverwisseling naar en uit die regio op ze toe- 
passen. Stel bijvoorbeeld dat we vier regio’s hebben, elk met een algoritme voor 
CVE-werkindeling bij toerbeurt. Wanneer een quantum afloopt zou het program- 
ma voor geheugenbeheer de job die juist zijn quantum gehad heeft willen verwis- 
selen voor een andere job in die regio. Intussen zou de CVE-werkindeler een 
tijdschijfje toekennen aan een job in een andere regio. Iedere job die met zijn 
quantum klaar is wordt verwisseld voor een andere job in die regio. Hopelijk kan 
het programma voor geheugenbeheer zo vlug programma’s verwisselen dat er 
altijd jobs, gereed voor uitvoering, in het geheugen zijn op het moment dat de 
CVE-werkindeler de CVE weer aan een andere job wil toewijzen. 

Een variant van dit programmaverwisselingsbeleid wordt gebruikt voor al- 
goritmen voor werkindeling die op prioriteit zijn gebaseerd. Als een job met hoge- 
re prioriteit aankomt en dienstverlening wenst, kan het programma voor geheu- 
genbeheer de job met lagere prioriteit verwisselen voor de job met hogere prio- 
riteit, om deze te laden en uit te voeren. Wanneer de job met hogere prioriteit 
klaar is, kan de job met lagere prioriteit in het geheugen teruggebracht worden 
en verder draaien. Deze variant van programmaverwisseling wordt soms roll-out/ 
roll-in genoemd. 

Gewoonlijk zal een job die in MFT uit het geheugen gezet is in dezelfde 
regio teruggebracht worden. Deze beperking wordt opgelegd door zowel het be- 
leid van het toewijzen van regio’s als door de methode van verplaatsing. Als op 
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het moment van het vertalen of laden verplaatsing plaatsvindt (statische verplaat- 
sing), kan de job niet naar een andere regio worden overgebracht. Met dynami- 
sche verplaatsing, zoals met een basis- en een limietregister, is het mogelijk een 
job terug te brengen in een andere regio. 

We zagen in hoofdstuk 2 dat een draaiend programma verzoeken om meer 
geheugen aan het systeem kan doen (Getmain/Freemain op de IBM-systemen 
bijvoorbeeld). Deze voorziening biedt een programma de mogelijkheid zijn ge- 
heugeneisen dynamisch, gebaseerd op zijn invoergegevens, in plaats van statisch 
te bepalen. Deze faciliteit kan evenwel problemen geven voor een geheugen- 
beheersbeleid zoals in MFT. Stel dat we een job van 4K hebben die in een regio 
van 6K geplaatst is. De job kan vrijelijk geheugen aanvragen en weer vrijgeven 
zolang hij niet meer dan 6K tegelijk aanvraagt (de grootte van de regio). Merk 
op dat deze aanvragen niet echt invloed hebben op de hoeveelheid geheugen die 
aan de job is toegewezen. De job heeft altijd 6K geheugen, ook al gebruikt hij 
slechts 4K. 

Wat kan het systeem doen als de job nog meer geheugen aanvraagt? Er zijn 
drie hoofdmogelijkheden: 


@ We kunnen de job beëindigen. Als we van de gebruiker eisen dat hij de maxi- 
male hoeveelheid geheugen die de job nodig zal hebben opgeeft, en we gebrui- 
ken deze waarde om een regio uit te kiezen, dan is een verzoek om geheugen- 
ruimte groter dan de regio een fout tijdens de uitvoering. 

@ We kunnen gewoon de besturing aan het gebruikersprogramma teruggeven, 
met een status-indicatie dat er geen geheugen meer is. Het gebruikersprogram- 
ma kan dan óf stoppen óf zijn verwerking wijzigen om binnen de beschikbare 
ruimte te werken. Veel algoritmen bieden een compromis tussen ruimte ener- 
zijds en tijd anderzijds: meer ruimte geeft het programma gelegenheid sneller 
te draaien, maar het kan (zij het langzamer) draaien in minder geheugenruimte. 

@ We kunnen (1) de job verwisselen, (2) wachten tot een grotere regio ter beschik- 
king komt, (3) de job terugbrengen in de grotere regio (met verplaatsing van 
de job al naar gelang dit nodig is), en (4) de uitvoering vervolgen. Deze oplos- 
sing is alleen mogelijk wanneer de apparatuur dynamische verplaatsing onder- 
steunt, en kan heel kostbaar zijn, maar hij geeft programma’s een zo groot 
mogelijke flexibiliteit in het naar behoefte wijzigen van hun geheugeneisen. 


Vergeet ook niet dat, als het besturingssysteem door het toepassingsprogramma 
op de hoogte gehouden wordt van de werkelijke hoeveelheid geheugen die het 
nodig heeft, de tijd benodigd voor programmaverwisseling kan worden terugge- 
bracht. Indien een regio van 12K is toegewezen aan een programma dat maar 
8K gebruikt, dan hoeft maar 8K te worden verwisseld. 


Keuze van de regiogrootte 
Een ander ontwerpprobleem in MFT heeft te maken met het bepalen van de 
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grootte van de regio’s. Als we in totaal 32K geheugen hebben en een residente 
monitor van 10K, hebben we 22K over om onder de gebruikers te verdelen. We 
moeten beslissen hoeveel regio’s we opzetten en hoe groot die zijn. De aanvanke- 
lijke beslissing wordt in het algemeen gebaseerd op een redelijke schatting van 
de geheugeneisen van de ingevoerde programma’s. Voor een systeem voor groeps- 
gewijze verwerking waarop kleine I/O-functieprogramma’s (van 1K tot 3K), een 
FORTRAN-compileerprogramma van 8K en een assembleerprogramma van 4K 
zullen draaien, zouden we een regio kunnen opzetten van 10K voor het com- 
pileerprogramma en andere grote programma’s en twee regio’s van 4K voor 
1/O-programma’s en het assembleerprogramma. Aangezien deze indeling nog 4K 
niet-toegewezen ruimte overlaat, zouden we de regio van 10K kunnen ophogen 
tot 14K, of één regio van 4k tot 8K, of beide regio’s van 4K tot 6K. 

Wanneer het systeem eenmaal gebruiksklaar is, kunnen we informatie ver- 
zamelen over het aantal en de grootte van de jobs die echt worden verwerkt. Deze 
Statistische cijfers zouden kunnen aangeven dat een andere verzameling regio’s 
beter zou zijn. 

Het voornaamste probleem met MFT is het vinden van een manier waarop 
de feitelijke geheugeneisen van jobs goed binnen de regio’s passen. Het totale 
prestatievermogen van een computersysteem is in het algemeen evenredig met het 
multiprogrammeringsniveau; het multiprogrammeringsniveau wordt rechtstreeks 
beïnvloed door de vraag hoe goed ons geheugenbeheer is. Als de helft van het 
geheugen niet gebruikt wordt, zouden we tweemaal zoveel jobs kunnen draaien 
door een manier te vinden om die ruimte wel te gebruiken. 


Fragmentatie van het geheugen 

Een job die m geheugenwoorden nodig heeft kan worden gedraaid in een regio 
van n woorden, waarbij n > m. Het verschil tussen deze twee getallen (n — m) 
is de interne fragmentatie, geheugen dat zich binnen een regio bevindt maar niet 
wordt gebruikt. Externe fragmentatie treedt op wanneer een regio ongebruikt is 
en beschikbaar, maar te klein voor een van de wachtende jobs. Beide soorten 
fragmentatie vormen een bron van geheugenverspilling in MFT. 

Stel bijvoorbeeld dat we een gebruikersruimte van 22K opdelen in een regio 
van 10K en drie regio’s van 4K. Indien onze job-wachtrij jobs bevat die 7K, 3K, 
6K en 6K nodig hebben, kunnen we de job van 7K aan de regio van 10K toe- 
wijzen (waarbij we 3K interne fragmentatie produceren) en de job van 3K aan 
een van de regio’s van 4K (1K interne fragmentatie). Omdat de twee overblijven- 
de jobs te groot zijn voor de beschikbare regio’s, zitten we met twee onbruikbare 
regio’s van elk 4K, een totale externe fragmentatie van 8K. Onze totale fragmen- 
tatie, intern en extern, bedraagt 12K, meer dan de helft van ons geheugen. 

Als we het geheugen verdelen in regio’s van 10K, 8K en 4K, zouden we de 
job van 7K in de regio van 8K kunnen draaien en de job van 3K in de regio van 
4K, hetgeen een interne fragmentatie oplevert van 2K. Afhankelijk van onze job- 
werkindeler zouden we beide jobs van 6K laten wachten (resulterend in 10K 
externe fragmentatie) of een van beide in de regio van 10K laten draaien. Als we 
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één job laten draaien, produceren we nog eens 4K interne fragmentatie, maar 
zijn we de externe fragmentatie kwijt. Als onze regio’s precies even groot waren 
als de jobs, zouden we alle 4 jobs kunnen draaien zonder interne of externe frag- 
mentatie. 


5.5.3 Variabele partities (MVT) 


Het voornaamste probleem met MFT is het bepalen van de beste regiogrootte en 
het zo klein mogelijk maken van de interne en externe fragmentatie. Helaas is er, 
met een dynamische verzameling van te draaien jobs, waarschijnlijk geen enkele 
juiste verdeling van het geheugen. Neem bijvoorbeeld aan dat 120K geheugen 
beschikbaar is voor gebruikersprogramma’s en dat alle gebruikersjobs 20K zijn, 
behalve één grote job van 80K die eenmaal per dag draait. We moeten een regio 
van 80K bestemmen voor het draaien van dit programma, maar aangezien alle 
andere jobs 20K zijn, zitten we met 60K (de helft van het gebruikersgeheugen) 
interne fragmentatie, behalve wanneer die ene grote job eenmaal per dag draait. 

Er is een oplossing voor dit probleem: we bieden de mogelijkheid dat de 
regiogrootte dynamisch verandert. Deze benadering noemt men het toewijzen van 
meerdere aaneensluitende variabele partities. We gebruiken de naam MVT om 
deze groep algoritmen voor geheugenbeheer aan te duiden, naar aanleiding van 
OS/360 MVT (multiprogrammering met een variabel aantal taken). 

Het geheugenbeheer van MVT is tamelijk simpel. Het besturingssysteem 
houdt een tabel bij die aangeeft welke delen van het geheugen beschikbaar en 
welke bezet zijn. In het begin is al het geheugen voor gebruikersprogramma’s 
beschikbaar en wordt dit beschouwd als één groot blok beschikbaar geheugen, 
een gat. Wanneer een job aankomt en geheugen nodig heeft, zoeken we een gat 
dat groot genoeg is voor deze job. Als we er een vinden, wijzen we slechts zoveel 
geheugen toe als nodig is, waarbij we de rest beschikbaar houden om te voldoen 
aan toekomstige verzoeken. 

Stel bijvoorbeeld dat we beschikken over 256K geheugen en dat we een 
residente monitor van 40K hebben. Deze situatie laat 216K over voor gebruikers- 
programma’s, zoals aangegeven in figuur 5.15. Met de in de figuur gegeven job- 
wachtrij en werkindeling volgens WEKEM, kunnen we onmiddellijk geheugen 
toewijzen aan de jobs 1, 2 en 3, met als resultaat het geheugenoverzicht van figuur 
5.16(a). We hebben 26K externe fragmentatie. Met gebruikmaking van een algo- 
ritme voor CVE-werkindeling bij toerbeurt met een quantum van 1 tijdseenheid, 
zal job 2 eindigen op tijdstip 14 en zijn toegewezen geheugen vrijgeven. Deze 
situatie wordt weergegeven in figuur 5.16(b). Dan gaan we terug naar onze job- 
wachtrij en selecteren de volgende job, job 4, met als resultaat de geheugenin- 
deling van figuur 5.16(c). Job 1 zal eindigen op tijdstip 28, weergegeven in figuur 
5.16(d), en job 5 wordt dan geselecteerd, hetgeen figuur 5.16(e) oplevert. 

Dit voorbeeld laat verschillende dingen van MVT zien. In het algemeen is 
er op elk moment een verzameling gaten, van verschillende grootte, die over het 
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Job-wachtrij 
monitor Job Geheugen Duur 

1 60K 10 

40K 2 100K 5 

3 30K 20 

4 70K 8 

5 50K 15 

216K 

256K 
Figuur 5.15 


Voorbeeld van werkindeling in MVT 


geheugen verspreid liggen. Wanneer een job arriveert en geheugen nodig heeft, 
zoeken we in deze verzameling naar een gat dat groot genoeg is voor deze job. Is 
het gat te groot, dan wordt het in tweeën gesplitst: één deel wordt toegewezen 
aan de job die zojuist gearriveerd is; het andere deel wordt teruggegeven aan de 
verzameling van gaten. Wanneer een job eindigt, geeft hij zijn geheugenblok vrij, 
dat dan terug wordt gezet in de verzameling van gaten. Als het nieuwe gat grenst 
aan andere gaten, zouden we deze gaten willen samenvoegen tot één groot gat. 
Op dit moment moeten we wellicht controleren of er jobs op geheugen wachten 
en of dit zojuist vrijgegeven en opnieuw gecombineerde stuk geheugen aan de 
eisen van één van deze wachtende jobs zou kunnen voldoen. 

Deze werkwijze is een speciale toepassing van het algemene probleem van 
dynamische geheugentoewijzing, dat we besproken hebben in paragraaf 3.4.2. De 
meest voorkomende algoritmen voor het toewijzen van geheugen zijn eerst- 
passend en best-passend. 

Wanneer een geheugenblok eenmaal aan een job is toegewezen, kan zijn 
programma in die ruimte worden geladen en uitgevoerd. De minimaal benodigde 
ondersteuning door de apparatuur is dezelfde als bij MFT: twee registers die 
boven- en ondergrenzen bevatten van de geheugenregio die aan deze job is toe- 
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100KF 100K 
oe =f 
job 2 geheugen- 


eindigt toewijzing 


job 4 
170K 
200K 200K 
230K 230K 
256K 256K 


Figuur 5.16 
Voorbeeld van geheugentoewijzing en job-werkindeling in MVT 


gewezen. Wanneer de CVE-werkindeler dit proces selecteert, laadt het verdeel- 
programma de juiste waarden in deze grensregisters. Omdat elk adres dat door de 
CVE wordt gegenereerd gecon roe? wordt aan de hand van deze twee registers, 
kunnen we de programma’s en gegevens van andere gebruikers beveiligen tegen 
wijziging door dit lopende proces. 

Let erop dat de programmatuur het verschil bepaalt tussen MFT en MVT; 
de apparatuur is identiek. 

Een ander probleem dat zich met MVT voordoet wordt geïllustreerd door 
figuur 5.17. Let op het gat van 18.464 bytes. Als de volgende job om 18.462 bytes 
verzoekt, wat doen we dan? Als we precies het gevraagde blok toewijzen, zitten 
we met een gat van 2 bytes. De overhead om dit gat ’in de gaten’ te houden weegt 
aanzienlijk zwaarder dan het gat zelf. De algemene taktiek is heel kleine gaten 
als onderdeel van het grotere verzoek toe te wijzen. Daarom kan het toegewezen 
geheugen enigszins groter zijn dan het aangevraagde geheugen, waardoor weer 
een kleine hoeveelheid interne fragmentatie wordt geïntroduceerd. De CDC 6600 
bijvoorbeeld, doet de geheugentoewijzing alleen in hoeveelheden van 64 woorden, 
de IBM 360 doet dit in hoeveelheden van 2K en de PDP-11 hire een blok 
van minimaal 8 woorden. 


Job-werkindeling in MVT 

Evenals dat het geval is met MFT, staat MVT in sterke wisent met de 
werkindeling voor jobs. Op elk gegeven moment hebben we een lijst van beschik- 
bare blokgrootten en een wachtrij van jobs met geheugenaanvragen. De job-wer- 


5.5 Meerdere partities 


een programma heeft 
18.462 bytes nodig gat van 
18.464 bytes 
Figuur 5.17 


Toewijzing vindt plaats in een veelvoud van bytes 


kindeler kan de volgorde binnen de wachtrij bepalen volgens een algoritme voor 
werkindeling. De jobs krijgen geheugen toegewezen totdat uiteindelijk aan de 
geheugeneisen van de volgende job niet kan worden voldaan; geen beschikbaar 
geheugenblok (gat) is groot genoeg. 

Het programma voor job-werkindeling kan dan wachten tot er een blok 
beschikbaar komt dat groot genoeg is, of het kan verder zoeken in de wachtrij 
om te zien of kan worden voldaan aan de geringere geheugeneisen van een job 
met een lagere prioriteit. Deze beslissing brengt een keuze met zich mee tussen 
CVE-werkindeling mét of zónder het overslaan van jobs in de wachtrij. 

De geheugen-gebruiksfactor is in het algemeen beter voor MVT dan voor 
MFT. Er is weinig of geen interne fragmentatie in MVT, aangezien de regio’s z6 
worden opgezet dat ze de door de job aangevraagde grootte hebben. We kunnen 
echter externe fragmentatie hebben. Als we nog even naar figuur 5.16 kijken 
kunnen we twee zulke situaties zien. In figuur 5.16(a) is er een totale externe 
fragmentatie van 26K, een ruimte die te klein is om aan een verzoek van een job 
te voldoen. In figuur 5.16(c) evenwel hebben we een totale externe fragmentatie 
van 56K (= 30K + 26K). Deze ruimte zou groot genoeg zijn om job 5 in te 
draaien (die 50K nodig heeft), behalve dan dat deze ruimte niet aaneengesloten 
is. De vrije-geheugenruimte is gefragmenteerd in twee stukken, waarvan er geen 
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op zichzelf groot genoeg is om aan de geheugenaanvrage van job 5 te voldoen. 

Dit fragmentatieprobleem kan zeer ernstig zijn. In het ergste geval zouden 
we een blok vrije (verspilde) ruimte hebben tussen elk tweetal jobs. Zou al dit 
geheugen als één groot vrij blok voorkomen, dan zouden we misschien diverse 
jobs meer kunnen draaien. De keuze tussen eerst-passend of best-passend kan 
op de hoeveelheid fragmentatie van invloed zijn. (Eerst-passend is beter voor 
sommige systemen en best-passend voor andere.) Een andere factor is welk eind 
van een vrij blok wordt toegewezen (welk stuk blijft over, dat aan de bovenkant 
of dat aan de onderkant?). Wat voor algoritmen er echter ook worden gebruikt, 
externe fragmentatie blijft een probleem. 


Comprimering 
Eén oplossing voor dit probleem is comprimering. Het doel is de inhoud van het 
geheugen te husselen om al het vrije geheugen in één groot blok bij elkaar te 
krijgen. Het geheugenoverzicht van figuur 5.16(e) bijvoorbeeld kan worden ge- 
comprimeerd, zoals aangegeven in figuur 5.18. De drie gaten ter grootte van 10K, 
30K en 26K, kunnen worden gecomprimeerd tot één gat van 66K. 

Comprimering is niet altijd mogelijk. Merk op dat we in figuur 5.18 de jobs 
4 en 3 hebben verschoven. Willen deze programma’s in staat zijn om in hun 
nieuwe posities te werken, dan moeten alle interne adressen worden verplaatst. 
Als de verplaatsing statisch is en gedaan wordt op het moment van het vertalen 
of laden, dan kan er geen comprimering plaatsvinden; comprimering is alleen 
mogelijk bij dynamische verplaatsing, ten tijde van de uitvoering, met behulp van 
een basis- en een limietregister. 

Als adressen dynamisch verplaatst worden (zoals op de CDC 6600), is voor 


0 

40K 

WIM, 3 On 90K 
aiia 
comprimeer 

160K 


Figuur 5.18 
Comprimering 
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verplaatsing alleen nodig dat we het programma en de gegevens verhuizen, en 
dat we vervolgens het basisregister wijzigen zodat dit het nieuwe basisadres weer- 
spiegelt. 

Is comprimering mogelijk, dan moeten we bepalen tegen welke prijs dit 
gebeurt. Het eenvoudigste algoritme voor comprimering is het gewoon opschui- 
ven van alle jobs naar het ene eind van het geheugen; alle gaten schuiven daarbij 
naar het andere eind, met als resultaat één groot gat van beschikbaar geheugen. 
Deze manier van werken kan heel duur zijn. 

Kijk eens naar de toewijzing van geheugen zoals aangegeven in figuur 5.19. 
Als we dit simpele algoritme gebruiken, moeten we jobs 3 en 4 opschuiven, in 
totaal 600K. In deze situatie zouden we eenvoudig job 4 boven job 3 kunnen 
schuiven, waardoor slechts 200K opgeschoven wordt. Let erop dat in dit laatste 
voorbeeld ons grote gat van beschikbaar geheugen niet aan het eind van het ge- 
heugen ligt, maar in het midden. Let er ook op dat als de wachtrij slechts één job 
bevatte die 450K wilde, we dat speciale verzoek konden inwilligen door job 2 
ergens anders heen te verschuiven (zoals onder job 8). Hoewel deze oplossing 
niet één groot gat creëert, levert hij een gat dat groot genoeg is om aan het volgen- 
de verzoek te voldoen. Het kiezen van een optimale comprimeringsstrategie is 
heel moeilijk. 

Het SCOPE-besturingssysteem voor de CDC 6600 maakte gebruik van een 
MVT geheugenbeheersbeleid met comprimering. Maximaal acht jobs mochten 
tegelijkertijd in het geheugen. Bij beëindiging van een job werd het geheugen 


oorspronkelijke 200K 
toewijzing geschoven geschoven geschoven 


« 1guur 5.19 
Vergelijking van enige verschillende manieren om geheugen te comprimeren 
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gecomprimeerd om alle vrije ruimte in één gat op de bodem van het geheugen te 
houden. 

Programmaverwisseling kan ook worden gecombineerd met MFT, evenals 
met andere systemen. Een job kan worden weggeschreven (rolled out) op een 
extern geheugen en later weer worden ingelezen (rolled in). Wanneer de job wordt 
weggeschreven, wordt zijn geheugen vrijgegeven en wellicht weer gebruikt voor 
een andere job. Moet de job weer worden ingelezen, dan kunnen zich diverse 
problemen voordoen. Als gebruik wordt gemaakt van statische verplaatsing, 
moet de job worden ingelezen in precies dezelfde geheugenposities die hij eerst 
innam. Deze beperking kan inhouden dat andere jobs moeten worden weg- 
geschreven om dat stuk geheugen vrij te maken. 

Als dynamische verplaatsing (zoals met een basis- en een limietregister) 
wordt gebruikt, kan een job in een andere positie worden ingelezen. In dit geval 
zoeken we een vrij blok op, comprimeren zonodig, en lezen de job in. 

Eén benadering bij comprimering is dat we die jobs die verschoven moeten 
worden wegschrijven en ze in andere geheugenposities weer inlezen. Als program- 
maverwisseling of roll-in/roll-out al deel van het systeem is, kan de extra code 
voor comprimering minimaal zijn. 

We kunnen ook de gemiddelde hoeveelheid externe fragmentatie vermin- 
deren door de gemiddelde grootte van een job te verminderen. Een andere be- 
naderingswijze, op verschillende machines gebruikt, bestaat uit het opbreken van 
het geheugen dat de job nodig heeft in twee delen; elk deel is kleiner dan het 
geheel. 

De PDP-10 heeft twee paar basis- en limietregisters. Het geheugen wordt 
in tweeën gesplitst door gebruik van de meest significante adres-bit. Het lage 
geheugen wordt verplaatst/ begrensd door het basis-/limietregisterpaar 0; het ho- 
ge geheugen wordt verplaatst/begrensd door het basis-/ limietregisterpaar 1. Ge- 
bruikelijk is dat compileer- en assembleerprogramma’s alleen-uitleesbare (read- 
only) waarden (zoals constanten en instructies) in het hoge geheugen en varia- 
belen in het lage geheugen zetten. Met elk registerpaar zijn beveiligingsbits ver- 
bonden om de hand te houden aan het alleen-uitleeskarakter van het hoge geheu- 
gen. Deze opzet zorgt ervoor dat programma’s (die in het hoge gedeelte van het 
geheugen als alleen-uitleesbaar zijn opgeslagen) gemeenschappelijk gebruikt kun- 
nen worden door vele gebruikersprogramma’s, die elk hun eigen afzonderlijke 
geheugensegment in het lage gedeelte van het geheugen hebben. 

De Univac 1108 heeft een soortgelijke opzet die gebaseerd is op een ander 
soort scheiding. De CVE weet of hij een instructie (instructie-ophaalopdracht) 
wil hebben of gegevens (gegevens-ophaal/opbergopdracht). Daarom heeft de 
Univac 1108 twee paar basis-/limietregisters; één voor instructies en één voor 
gegevens. Het basis-/limietregisterpaar voor instructies is automatisch alleen-uit- 
leesbaar, zodat meerdere gebruikers programma’s gemeenschappelijk kunnen ge- 
bruiken. | 

In beide gevallen kunnen we, door instructies en gegevens te scheiden en elk 
van beide afzonderlijk te verplaatsen, programma’s door verschillende gebruikers 
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gemeenschappelijk laten gebruiken. Op deze wijze maken we een beter gebruik 
van het geheugen: we brengen de fragmentatie terug en vermijden tevens dat er 
meer dan één kopie nodig is van dezelfde code, in het bijzonder gemeenschappe- 
lijk gebruikte code, zoals vertaalprogramma’s, tekstopmaakprogramma’s, enzo- 
voort. 


5.6 Paginering 


MVT lijdt aan externe fragmentatie. In het algemeen treedt deze situatie op wan- 
neer het beschikbare geheugen niet aaneengesloten is, maar gefragmenteerd, zo- 
dat er sprake is van veel verspreid liggende blokken. Omdat het geheugen dat 
aan een bepaalde job wordt toegewezen aaneengesloten moet zijn, kan dit ver- 
spreide, niet-aaneengesloten geheugen niet worden gebruikt. Dit probleem heeft 
twee algemene oplossingen. Comprimering wijzigt de toewijzing van het geheugen 
om de vrije ruimte aaneengesloten, en dus bruikbaar, te maken. Paginering staat 
toe dat het geheugen van een programma niet-aaneengesloten is en biedt aldus 
de mogelijkheid dat fysiek geheugen, waar dat ook maar beschikbaar is, aan een 
programma wordt toegewezen. 


5.6.1 Apparatuur 


De ondersteuning voor paginering door de apparatuur is weergegeven in figuur 
5.20. Elk adres dat door de CVE wordt gegenereerd wordt in twee delen verdeeld: 
een paginanummer (p) en een relatieve positie binnen de pagina (d). Het pagina- 
nummer wordt gebruikt als een index in een paginatabel. De paginatabel bevat 
het basisadres van elke pagina in het fysieke geheugen. Dit basisadres wordt 
gecombineerd met de relatieve positie binnen de pagina voor het definiëren van 
het fysieke geheugenadres dat naar de geheugeneenheid wordt gestuurd. | 

Het pagineringsmodel van het geheugen kan men zien in figuur 5.21. Het 
fysieke geheugen is opgedeeld in blokken van een vaste grootte, die kaders wor- 
den genoemd. Het logische geheugen is ook opgedeeld in blokken van dezelfde 
grootte, die pagina’s heten. Wanneer een programma moet worden uitgevoerd, 
worden zijn pagina’s in beschikbare kaders geladen, en wordt de paginatabel voor 
het vertalen van gebruikerspagina’s naar geheugenkaders gedefinieerd. 

De grootte van de pagina’s (en de kaders) wordt bepaald door de appara- 
tuur. De grootte van een pagina is meestal een macht van twee. De IBM/370 
bijvoorbeeld gebruikt 2048 of 4096 bytes per pagina, de XDS-940 gebruikte 2048 
woorden per pagina, de Nova 3/D gebruikt 1024 woorden per pagina en de DEC- 
10 gebruikt 512 woorden per pagina. De Atlas machine en de Sigma 7 gebruikten 
ook pagina’s van 512 woorden (zie figuur 5.22). Algemeen geldt: als de pagina- 
grootte P is, dan levert een logisch adres U een paginanummer p en een relatieve 
positie d op, volgens 
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paginatabel 
Figuur 5.20 
Pagineringsapparatuur 
p = U div P 
d = U mod P 


waarin div de gehele deling voorstelt en mod de bijbehorende rest. De keuze van 
een macht van twee voor de paginagrootte maakt het vertalen van een logisch 
adres in een paginanummer en relatieve positie bijzonder gemakkelijk. Als een 
pagina 2” adreseenheden (bytes of woorden) lang is, dan vormen de minst signifi- 
cante n bits van een logisch adres de relatieve positie en de overblijvende, meest 
significante, bits vormen dan het paginanummer. Dus als de paginagrootte een 
macht van twee is, kunnen we de deling vermijden. 

Om een concreet voorbeeld te geven kunnen we kijken naar het geheugen 
in figuur 5.23. Met gebruikmaking van een paginagrootte van 4 woorden en een 
fysiek geheugen van 32 woorden (8 pagina’s), laten we in een voorbeeld zien hoe 
de kijk van de gebruiker op het geheugen kan worden vertaald naar het fysieke 
geheugen. Logisch adres 0 is pagina 0, relatieve positie 0. Door indicering in de 
paginatabel blijkt dat pagina 0 zich bevindt in kader 5. Dus het logische adres 0 
wordt vertaald in het fysieke adres 20 (= 5X4 + 0). Logisch adres 3 (pagina 0, 
relatieve positie 3) wordt vertaald in fysiek adres 23 (= 5X4 + 3). Logisch adres 
4 is pagina 1, relatieve positie 0; volgens de paginatabel wordt pagina 1 vertaald 
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Figuur 5.21 
Pagineringsmodel van logisch en fysiek geheugen 


in kader 6. Dus logisch adres 4 wordt vertaald in fysiek adres (6X4 + 0 =) 24. 
Logisch adres 13 wordt vertaald in fysiek adres 9. 

Het is belangrijk op te merken dat paginering zelf een vorm van dynamische 
verplaatsing is. Elk logisch adres wordt door de pagineringsapparatuur vertaald © 
naar een fysiek adres. 


5.6.2 Job-werkindeling 


Zoals we eerder al zagen, beïnvloedt de wijze van geheugenbeheer het programma 
voor job-werkindeling. Wanneer een job arriveert om te worden uitgevoerd, on- 


Machine Adres Pagina Relatieve positie 
Atlas 20 11 9 
DEC-10 18 9 9 

Sigma 7 17 8 9 

Nova 3/D 15 5 10 
XDS-940 14 3 11 

IBM 370 24 13 of 12 11 of 12 

Figuur 5.22 


Aantal adresbits voor diverse computers met paginering 
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Pagineringsvoorbeeld voor een geheugen van 32 woorden met pagina’s van 4 woorden 


derzoekt het programma voor job-werkindeling zijn grootte. De grootte van een 
-job wordt uitgedrukt in pagina’s. Dan kijkt de job-werkindeler naar het beschik- 
bare geheugen, dat als een lijst van niet-toegewezen paginakaders wordt bijge- 
houden. Iedere gebruikerspagina heeft één kader nodig. Dus als de job n pagina’s 
nodig heeft, moeten er n kaders in het geheugen beschikbaar zijn. Zijn er n kaders 
beschikbaar, dan wijst de job-werkindeler ze toe aan deze job. De eerste pagina 
wordt in één van de niet-toegewezen kaders geladen en het kadernummer wordt 
in de paginatabel voor deze job gezet. De volgende pagina wordt in een ander 
kader geladen en zijn kadernummer wordt in de paginatabel gezet, enzovoort (zie 
figuur 5.24). 

Bij gebruikmaking van een pagineringsmethode hebben we geen externe 
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Figuur 5.24 
Toewijzing van vrije kaders: (a) vóór, en (b) na 


fragmentatie: elk vrij kader kan worden toegewezen aan een job die er een nodig 
heeft. We kunnen echter wel wat interne fragmentatie hebben. Merk op dat ka- 
ders worden toegewezen als eenheden. Als de geheugeneisen van een programma 
niet toevallig met paginagrenzen samenvallen, hoeft het laatst toegewezen kader 
niet helemaal vol te zijn. Met pagina’s van 512 woorden bijvoorbeeld zou een 
programma van 8629 woorden 16 pagina’s plus 437 woorden nodig hebben. Het 
zou 17 kaders toegewezen krijgen, wat een interne fragmentatie oplevert van 512 
— 437 = 75 woorden. In het ergste geval zou een programma n pagina’s plus 1 
woord nodig hebben. Het zou n + 1 kaders toegewezen krijgen, hetgeen resulteert 
in een interne fragmentatie van bijna een heel kader. Als de jobgrootte onafhan- 
kelijk is van de paginagrootte, zouden we een interne fragmentatie verwachten 
van een halve pagina per job. Deze overweging geeft al aan dat een kleine pagina- 
grootte wenselijk is. 

Iedere job heeft zijn eigen paginatabel, die met de andere registerwaarden 
(zoals de programmateller) wordt opgeslagen in het job-besturingsblok. Wanneer 
het verdeelprogramma wordt gezegd dat het een job moet starten, moet het de 
gebruikersregisters opnieuw laden en uit de opgeslagen paginatabel van de ge- 
bruiker de juiste waarden voor de paginatabel in de apparatuur bepalen. 
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5.6.3 Implementatie van de paginatabel 


De implementatie van de paginatabel in de apparatuur is van belang. In het 
eenvoudigste geval is de paginatabel geïmplementeerd als een groep van alleen 
voor dit doel gebruikte registers. De CVE-werkindeler laadt deze registers op- 
nieuw, evenals hij de andere registers van het programma opnieuw laadt. Instruc- 
ties voor het laden of wijzigen van de paginatabelregisters zijn natuurlijk bevoor- 
recht, zodat alleen het besturingssysteem de geheugenindeling kan wijzigen. Deze 
benadering werd gebruikt op de XDS-940, die 8 pagina’s van elk 2048 woorden 
had en 8 paginatabelregisters. De Nova 3/D heeft 32 pagina’s van elk 1024 woor- 
den, met 32 paginatabelregisters. De Sigma 7 had een paginanummer van 8 bits, 
zodat er 256 registers voor zijn paginatabel nodig waren. 

Er kunnen dus 8 tot 256 registers nodig zijn voor de paginatabel. Deze 
registers kunnen opgebouwd zijn uit logica met zeer hoge snelheid om de pagina- 
adresvertaling zeer efficiënt te laten verlopen. Aangezien elke toegang tot het 
geheugen via de paginatabel moet gaan, is efficiëntie een zaak van groot belang. 

Het gebruik van registers voor de paginatabel werkt bevredigend als de 
paginatabel redelijk klein is. De DEC-10 heeft echter 512 pagina’s, de IBM 370 
gaat tot 4096 pagina’s, terwijl het Multics-systeem potentieel 16.777.216 pagina’s 
heeft! Voor deze machines is het gebruik van snelle registers voor de implementa- 
tie van de paginatabel niet doenlijk. In plaats daarvan wordt de paginatabel in 
het hoofdgeheugen bewaard en wijst een paginatabel-basisregister (PTBR) naar 
de paginatabel. Het wijzigen van paginatabellen vereist alleen het wijzigen van 
dit ene register, waardoor de contextomschakelingstijd aanzienlijk wordt bekort. 

Het probleem met deze benadering is de tijd die nodig is voor de toegang 
tot een positie in het gebruikersgeheugen. Als we toegang willen krijgen tot posi- 
tie i, moeten we eerst de paginatabel indiceren met gebruikmaking van de waarde 
in het paginatabel-basisregister waarbij het paginanummer voor i moet worden 
opgeteld. Hiervoor is een geheugentoegang nodig. Deze geeft ons het kadernum- 
mer, dat dan gecombineerd wordt met de relatieve positie binnen de pagina om 
het werkelijke adres te krijgen. Dan hebben we toegang tot de gewenste plaats in 
het geheugen. In deze opzet zijn twee geheugentoegangen nodig om een woord te 
bereiken (één voor de paginatabel en één voor het woord zelf). Het geheugen 
wordt derhalve met een factor twee vertraagd. Deze vertraging zou onder de 
meeste omstandigheden niet kunnen worden getolereerd. 

De standaardoplossing voor dit probleem is het gebruik van een speciaal, 
klein geheugen in de apparatuur, dat onder verschillende namen bekend staat: 
associatieve registers, of tussengeheugen (Engels: cache), of een raadplegings- 
geheugen (Engels: look-aside memory), of een inhoud-adresseerbaar geheugen. 
Een groep associatieve registers is opgebouwd uit geheugen van zeer hoge snel- 
heid. Ieder register bestaat uit twee delen, een sleutel en een waarde. Wanneer de 
associatieve registers een gegeven krijgen, wordt dit gelijktijdig met alle sleutels 
vergeleken. Als het gegeven gevonden is, wordt het daarbij behorende waardeveld 
als uitvoergegeven gepresenteerd. Het zoeken verloopt zeer snel; de apparatuur 
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is echter erg duur. 

Associatieve registers worden als volgt in combinatie met paginatabellen 
gebruikt. De associatieve registers bevatten slechts een paar paginatabelingangen. 
Wanneer een logisch adres door de CVE wordt gegenereerd, wordt het pagina- 
nummer daarvan doorgegeven aan een groep associatieve registers die pagina- 
nummers en de daarmee corresponderende kadernummers bevatten. Als het pa- 
ginanummer in de associatieve registers gevonden wordt, is zijn kadernummer 
onmiddellijk beschikbaar en wordt dit gebruikt om het geheugen in te gaan. Dit 
alles kan minder dan 10% langer duren dan een geheugenverwijzing zonder adres- 
vertaling. 

Bevindt het paginanummer zich niet in de associatieve registers, dan moet 
er een geheugenverwijzing naar de paginatabel plaatsvinden. Wanneer het kader- 
nummer verkregen is, kunnen we dit gebruiken voor de geheugentoegang (die we 
wilden). Bovendien voegen we het paginanummer en kadernummer toe aan de 
associatieve registers, zodat ze bij de volgende verwijzing heel snel gevonden zul- 
len worden. 

Het percentage van het aantal malen dat een paginanummer in de associa- 
tieve registers gevonden wordt (de trefkans; Engels hit ratio) houdt duidelijk ver- 
band met het aantal associatieve registers. Met 8 of 16 associatieve registers kan 
een trefkans van 80 tot 90% worden gehaald. Een trefkans van 80% betekent dat 
we in 80 procent van de gevallen het paginanummer in de associatieve registers 
vinden. Als het 50 nanoseconden duurt om de associatieve registers te doorzoe- 
ken, en 750 nanoseconden voor een geheugentoegang, duurt een geheugentoe- 

gang met adresvertaling wanneer het paginanummer in de associatieve registers 

staat 800 nanoseconden. Als we het paginanummer niet vinden (50 ns), moeten 
we eerst toegang zoeken tot het geheugen voor het kadernummer in de pagina- 
tabel (750 ns), en dan het gewenste woord in het geheugen benaderen (750 ns), 
zodat het totaal uitkomt op 1550 nanoseconden. Om de effectieve geheugentoe- 
gangstijd te vinden, moeten we aan elk geval een gewichtsfactor gelijk aan zijn 
waarschijnlijkheid toekennen: 


effectieve toegangstijd = 0,80x 800 + 0,20 x 1550 
= 950 nanoseconden 


In dit voorbeeld ondervinden we een vertraging in geheugentoegangstijd van 
26,6% (van 750 naar 950 nanoseconden). 
Voor een trefkans van 90% hebben we 


0,90 x 800 + 0,10 Xx 1550 
875 nanoseconden 


effectieve toegangstijd 


Deze grotere trefkans geeft slechts een vertraging van 16,6%. 
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5.6.4 Gemeenschappelijk gebruik van pagina’s 


Een ander voordeel van paginering is de mogelijkheid van het gemeenschappelijk 
gebruik van algemene code. Deze overweging is van bijzonder belang in een om- 
geving met tijddeling. Neem een systeem dat 40 gebruikers ondersteunt, waarbij 
iedere gebruiker een tekstopmaakprogramma gebruikt. Als het tekstopmaakpro- 
gramma uit code van 30K en uit 5K gegevensruimte bestaat, zouden we 1400K 
nodig hebben om de 40 gebruikers te ondersteunen. Als de code evenwel *herbe- 
treedbaar’ (Engels: re-entrant) is, zou hij gemeenschappelijk kunnen worden ge- 
bruikt, zoals in figuur 5.25 is weergegeven. Hier zien we een tekstopmaakpro- 
gramma (’topm’) van drie pagina’s dat gemeenschappelijk gebruikt wordt door 
drie processen. Elk proces heeft zijn eigen pagina met gegevens. 
Herbetreedbare code (ook zuivere code genoemd) is niet-zichzelf-wijzigen- 
de code. Als de code herbetreedbaar is, verandert deze nooit tijdens de uitvoering 
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Figuur 5.25 
Gemeenschappelijk gebruikte code in een pagineringsomgeving 
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ervan. Daarom kunnen twee of meer processen dezelfde code op hetzelfde tijdstip 
uitvoeren. Elk proces heeft zijn eigen kopie van registers en gegevensopslag om de 
gegevens voor zijn uitvoering vast te houden. De gegevens voor twee verschillende 
processen zullen natuurlijk voor elk proces anders zijn. 

Er hoeft slechts één kopie van het tekstopmaakprogramma in het fysieke 
geheugen gehouden te worden. De paginatabel van iedere gebruiker verwijst naar 
een en hetzelfde tekstopmaakprogramma, maar de gegevenspagina’s verwijzen 
naar verschillende kaders. Dus om 40 gebruikers te ondersteunen hebben we 
maar één tekstopmaakprogramma nodig (30K), plus 40 maal de 5K gegevens- 
ruimte per gebruiker. De totaal vereiste ruimte is nu 230K, in plaats van 1400K, 
een aanzienlijke besparing. 

Andere veel gebruikte programma’s kunnen ook gemeenschappelijk worden 
gebruikt: compileerprogramma’s, assembleerprogramma’s, database-systemen, 
enzovoort. Voor gemeenschappelijk gebruik moet de code herbetreedbaar zijn 
(niet-zichzelf-wijzigend). Deze term betekent dat nooit moet worden geprobeerd 
om iets op te bergen in de code; deze is alleen-uitleesbaar (Engels: read-only) of 
alleen-ophaalbaar (Engels: fetch only). Het is klaarblijkelijk essentieel dat ge- 
meenschappelijk gebruikte pagina’s ongewijzigd blijven. Als één gebruiker de in- 
houd van een geheugenplaats zou veranderen, zou deze voor alle gebruikers ver- 
anderen. Het alleen-uitleeskarakter van gemeenschappelijk gebruikte code moet 
niet worden overgelaten aan de juistheid van de code; het besturingssysteem 
moet ervoor zorgen dat deze eigenschap wordt gehandhaafd. 


5.6.5 Beveiliging 


Geheugenbeveiliging in een omgeving met paginering wordt tot stand gebracht 
door beveiligingsbits die bij iedere pagina behoren. Normaliter worden deze bits 
bewaard in de paginatabel. Een bit kan aangeven dat een pagina voor lees- en 
schrijfbewerkingen is of alleen-uitleesbaar. Elke verwijzing naar het geheugen 
gaat via de paginatabel om het juiste kadernummer te vinden. Op hetzelfde mo- 
ment dat het fysieke adres wordt berekend, kunnen de beveiligingsbits worden 
gecontroleerd om te verifiëren dat geen schrijfbewerkingen plaatsvinden naar een 
alleen-uitleesbare pagina. Een poging om naar een alleen-uitleesbare pagina te 
schrijven veroorzaakt een ’val’ van de apparatuur naar het besturingssysteem 
(schending van de geheugenbeveiliging). 

Deze benaderingswijze van beveiliging kan gemakkelijk worden uitgebreid 
om een fijnere graad van beveiliging te krijgen. We kunnen apparatuur leveren 
voor het verschaffen van beveiliging voor alleen-uitleesbaar geheugen, alleen-uit- 
voerbaar geheugen, of lees-schrijfgeheugen. Of men kan, door afzonderlijke bits 
voor elk van deze soorten toegang te verzorgen, iedere combinatie van deze ma- 
nieren van toegang toestaan, waarbij illegale pogingen in de ’val’ van het bestu- 
ringssysteem lopen. 

In het algemeen is er nog een bit met elke ingang in de paginatabel verbon- 
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den: een geldig/ongeldig-bit. De architectuur van de machine bepaalt een maxi- 
maal interval van adressen die kunnen worden gegenereerd. Bijvoorbeeld, een 
adres van 16 bits laat adressen toe in het interval 0 tot en met 65.535; een adres 
van 24 bits laat adressen toe in het interval 0 tot en met 16.777.215. Elk specifiek 
programma is echter in het algemeen beperkt tot een kleinere adresruimte, afhan- 
kelijk van het programma. Met de apparatuur van de grensregisters kunnen we 
onjuiste door het programma gegenereerde adressen in de ‘val’ laten lopen. 

Illegale adressen worden betrapt door een geldig/ongeldig-bit te gebruiken. 
Het besturingssysteem zet deze bits voor elke pagina, om al of niet toegang tot 
deze pagina toe te staan. In een systeem met een 14-bits adresruimte bijvoorbeeld 
(0 tot en met 16.383) kunnen we een programma hebben dat alleen de adressen 
0 tot en met 10.468 mag gebruiken. Met een paginagrootte van 2K krijgen we de 
situatie van figuur 5.26. Adressen in de pagina’s 0, 1, 2, 3, 4 en 5 worden normaal 
via de paginatabel vertaald. Elke poging echter om een adres in pagina’s 6 en 7 
te genereren stuit op het geldig/ongeldig-bit dat op ongeldig gezet is, en de com- 
puter zal een ’val’ naar het besturingssysteem veroorzaken (ongeldige paginaver- 
wijzing). 

Let erop dat, aangezien het programma slechts tot adres 10.468 gaat, elke 
verwijzing voorbij dat adres illegaal is. Verwijzingen naar pagina 5 zijn echter 
geclassificeerd als geldig, zodat de toegang tot adressen tot en met 12.287 geldig 
is. Slechts de adressen 12.288 tot en met 16.383 zijn ongeldig. Dit probleem is 
een gevolg van de paginagrootte van 2K en weerspiegelt de interne fragmentatie 
van paginering. 

De XDS-940 had aan elke pagina een bit toegevoegd voor de besturing van 
alleen-uitleestoegang (Read-Only, RO) of lees-schrijftoegang (Read-Write, RW). 
Een kadernummer 0 werd opgevat als een ongeldige ingang in de paginatabel. 
De ontwerpers gingen uit van de redenering dat het besturingssysteem kader 0 
van het geheugen bezet zou houden en dat daarom geen paginatabel ooit als 
resultaat van de adresvertaling kader 0 zou geven. 


5.6.6 Tweeërlei kijk op het geheugen 


Een zeer belangrijk aspect van paginering is de duidelijke scheiding tussen de 
kijk van de gebruiker op het geheugen en het werkelijke fysieke geheugen. Het 
gebruikersprogramma gelooft dat het geheugen één aaneengesloten ruimte is, die 
alleen dit ene programma bevat. In werkelijkheid is het gebruikersprogramma 
verpreid over het gehele fysieke geheugen, dat ook andere programma’s bevat. 
De kijk van de gebruiker en het werkelijke fysieke geheugen worden met elkaar 
in overeenstemming gebracht door de apparatuur voor de adresvertaling (Engels: 
adress translation of mapping). Deze apparatuur vertaalt logische adressen in fy- 
sieke adressen. Het vertalen is onzichtbaar voor de gebruiker en wordt bestuurd 
door het besturingssysteem. 

Eén gevolg van de scheiding van logische en fysieke adressen is dat ze in 
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Figuur 5.26 
Geldig- (g) of ongeldig-bit (0) in een paginatabel 


feite niet hetzelfde hoeven te zijn. Op de XDS-940 bijvoorbeeld is een logisch 
adres 14 bits; een fysiek adres is 16 bits. Een paginanummer van 3 bits is een 
index in de paginatabel om een kadernummer van 5 bits op te leveren. Zo kan 
er tot vier keer zoveel geheugen zijn als een willekeurige gebruiker kan adresseren. 
Multiprogrammering is gemakkelijk: er kunnen ten minste vier gebruikers gelijk- 
tijdig in het geheugen verblijven. 

Deze techniek werd vooral overgenomen door de fabrikanten van minicom- 
puters. Veel minicomputers werden ontworpen in de jaren ’60, toen geheugen 
duur was en de programma’s klein moesten zijn. Zo waren de meeste adressen 
beperkt tot 15 of 16 bits. Met het beschikbaar komen van de goedkopere half- 
geleidergeheugens werd het mogelijk deze computers met meer fysiek geheugen 
uit te rusten. Maar het opvoeren van de adresgrootte tot 17 of 18 bits, nodig 
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voor het toegenomen fysieke geheugen, betekende dat óf de instructieset opnieuw 
ontworpen moest worden óf dat de woordgrootte moest worden uitgebreid om 
de extra bits te kunnen bergen. Elk van beide oplossingen zou een belangrijke 
verandering met zich meebrengen, die alle bestaande programma’s en documen- 
tatie ongeldig zou maken. De oplossing die de meeste fabrikanten hebben ge- 
volgd is adresvertaling. Logische adressen (15 of 16 bits) worden vertaald in gro- 
tere adressen (van 17 of 18 bits). Door multiprogrammering van het systeem kan 
al het geheugen worden gebruikt. Individuele gebruikers kunnen echter niet méér 
geheugen gebruiken dan voordien, aangezien de logische adresruimte niet groter 
is geworden. 

Bijvoorbeeld, de Nova 3/D vertaalt een paginanummer van 5 bits in een 
kadernummer van 7 bits. De HP 2100 doet hetzelfde. De DEC-10 vertaalt een 
paginanummer van 9 bits in een kadernummer van 13 bits, daarbij een logisch 
adres van 18 bits veranderend in een fysiek adres van 22 bits. 

Het besturingssysteem bestuurt dit vertalen en kan dit aanzetten voor de 
gebruiker en afzetten voor het besturingssysteem. Aangezien het besturingssys- 
teem het fysieke geheugen beheert, moet het kennis hebben van de aard van het 
fysieke geheugen: welke kaders zijn toegewezen, welke kaders zijn beschikbaar, 
hoeveel kaders zijn er in totaal, enzovoort. Deze informatie wordt in het algemeen 
bijgehouden in een gegevensstructuur die kadertabel wordt genoemd. De kader- 
tabel heeft een ingang voor elk fysiek paginakader om aan te geven of dit vrij is 
of toegewezen en, indien dat zo is, aan welke pagina van welk proces. 

Bovendien moet het besturingssysteem kennis hebben van het feit dat ge- 
bruikersprocessen in de gebruikersruimte werken, en dat alle logische adressen 
moeten worden vertaald in fysieke adressen. Als een gebruiker een systeemaan- 
roep doet (voor I/O bijvoorbeeld), en een adres als parameter meegeeft (bijvoor- 
beeld van een buffer), moet dat adres worden vertaald om het juiste fysieke adres 
te krijgen. Het besturingssysteem houdt de paginatabel voor elke gebruiker bij, 
op dezelfde wijze als het de programmateller en de registerinhouden bijhoudt. 
Deze paginatabel wordt gebruikt om logische adressen te vertalen in fysieke 
adressen wanneer het besturingssysteem zelf een logisch adres moet vertalen in 
een fysiek adres. Hij wordt ook gebruikt door het verdeelprogramma om de pa- 
ginatabel in de apparatuur vast te leggen wanneer de CVE aan een proces moet 
worden toegewezen. 


5.7 Segmentering 


Een belangrijk aspect van geheugenbeheer, dat onvermijdelijk werd bij pagine- 
ring, is de scheiding tussen de kijk van de gebruiker op het geheugen en het 
werkelijke fysieke geheugen. Wat de gebruiker van het geheugen ziet is niet het- 
zelfde als het fysieke geheugen. Wat de gebruiker ziet wordt vertaald naar fysiek 
geheugen. De vertaling maakt het onderscheid mogelijk tussen logisch geheugen 
en fysiek geheugen. 


5.7 Segmentering 


5.7.1 De kijk van de gebruiker op het geheugen 


Hoe ziet de gebruiker het geheugen werkelijk? Denkt de gebruiker aan het geheu- 
gen als een lineaire reeks woorden, waarvan sommige instructies en andere gege- 
vens bevatten, of is er een andere favoriete kijk op het geheugen? Men is het er 
algemeen over eens dat de gebruiker of programmeur van een systeem niet aan 
het geheugen denkt als een lineaire reeks woorden. In plaats daarvan ziet de 
gebruiker het geheugen bij voorkeur als een verzameling segmenten van verschil- 
lende grootte, zonder dat deze segmenten onderling geordend hoeven te zijn (zie 
figuur 5.27). 

Ga eens na hoe u aan een programma denkt wanneer u dat aan het schrijven 
bent. U denkt daaraan als een hoofdprogramma met een verzameling subrou- 
tines, procedures, functies of modulen. Er kunnen ook diverse gegevensstructuren 
zijn, tabellen, reeksen, stapels, variabelen, enzovoort. Naar elk van deze modulen 
of gegevenselementen wordt verwezen met behulp van de naam. U spreekt over 
de ’symbolentabel’, ‘functie Vkw’, ’het hoofdprogramma’, zonder u erom te be- 
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Figuur 5.27 
Hoe de gebruiker een programma ziet 
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kommeren welke geheugenadressen deze elementen bezetten. Het kan u niet 
schelen of de symbolentabel voor of achter de functie Vkw is opgeslagen. Elk 
van deze segmenten heeft een variabele lengte; de lengte is intrinsiek bepaald 
door het doel dat het segment in het programma vervult. Elementen binnen een 
segment worden gedefinieerd door hun relatieve positie gerekend vanaf het begin 
van het segment: de eerste opdracht van het programma, de zeventiende ingang 
in de symbolentabel, de vijfde instructie van de Vkw-functie, enzovoort. 

Segmentering is een manier van geheugenbeheer die deze kijk van de gebrui- 
ker op het geheugen ondersteunt. Een logische adresruimte is een verzameling 
segmenten. Ieder segment heeft een naam en een lengte. Adressen specificeren 
zowel de naam van het segment als de relatieve positie binnen het segment. De 
gebruiker specificeert daarom elk adres met behulp van twee grootheden: de 
naam van een segment en een relatieve positie. (Vergelijk deze manier met pa- 
ginering, waarin de gebruiker slechts een enkel adres specificeerde, dat door de 
apparatuur werd opgedeeld in een paginanummer en een relatieve positie, alle- 
maal onzichtbaar voor de programmeur.) 

Om de implementatie eenvoudig te houden worden de segmenten genum- 
merd en wordt naar de segmenten verwezen met behulp van een segmentnummer 
in plaats van een segmentnaam. Gewoonlijk wordt het gebruikersprogramma 
geassembleerd (of gecompileerd), en het assembleerprogramma (of compileerpro- 
gramma) construeert automatisch segmenten die een afspiegeling vormen van het 
ingevoerde programma. Een Pascal-compileerprogramma zou aparte segmenten 
kunnen creëren voor (1) de globale variabelen, (2) de stapel voor procedure-aan- 
roepen, om parameters en terugkeeradressen op te bergen, (3) het code-gedeelte 
van elke procedure of functie, en (4) de lokale variabelen van elke procedure en 
functie. Een FORTRAN-compileerprogramma zou een apart segment kunnen 
creëren voor elk gemeenschappelijk blok. Aan reeksen zouden afzonderlijke seg- 
menten kunnen worden toebedeeld. Het laadprogramma neemt dan al deze seg- 
menten op en kent er segmentnummers aan toe. 


5.7.2 Apparatuur 


Hoewel de gebruiker nu naar objecten in het programma kan verwijzen door 
middel van een tweedimensionaal adres, is het werkelijke fysieke geheugen na- 
tuurlijk nog steeds een eendimensionale reeks woorden. Dus moeten we een im- 
plementatie ontwerpen om tweedimensionale door de gebruiker gedefinieerde 
adressen te vertalen in eendimensionale fysieke adressen. Deze vertaling komt 
tot stand met behulp van een segmenttabel. 

Het gebruik van een segmenttabel wordt geïllustreerd in figuur 5.28. Een 
logisch adres bestaat uit twee gedeelten: een segmentnummer s en een relatieve 
positie binnen dat segment d. Het segmentnummer wordt gebruikt als een index 
in de segmenttabel. Elke ingang in de segmenttabel heeft een segmentbasis en 
een segment/imiet. De relatieve positie d van het logische adres moet liggen tussen 
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Figuur 5.28 
Segmenteringsapparatuur 


0 en de segmentlimiet. Als dat niet het geval is, treedt een ’val’ in werking naar 
het besturingssysteem (logische adresseringspoging voorbij einde segment). Is de 
relatieve positie legaal, dan wordt deze bij de segmentbasis opgeteld om het fysie- 
ke geheugenadres van het gewenste woord te krijgen. De segmenttabel is dus in 
essentie een reeks van basis- en limietregisterparen. 

Neem als voorbeeld de situatie die figuur 5.29 laat zien. We hebben vijf 
segmenten met de nummers 0 tot en met 4. De segmenten zijn in werkelijkheid 
opgeslagen in het fysieke geheugen, zoals is aangegeven. De segmenttabel heeft 
een afzonderlijke ingang voor elk segment, aangevende het beginadres van het 
segment in het fysieke geheugen (de basis) en de lengte van dat segment (de 
limiet). Segment 2 bijvoorbeeld is 400 woorden lang en begint op positie 4300. 
Dus een verwijzing naar woord 53 van segment 2 wordt vertaald in positie 4300 
+ 53 = 4353. Een verwijzing naar segment 3, woord 852, wordt vertaald in 3200 
(de basis van segment 3) + 852 = 4052. Een verwijzing naar woord 1222 van 
segment 0 zou een ‘val’ naar het besturingssysteem tot gevolg hebben, aangezien 
het segment slechts 1000 woorden lang is. 


5.7.3 Implementatie van segmenttabellen 


Evenals de paginatabel kan de segmenttabel in snelle registers of in het geheugen 
gezet worden. Verwijzing naar een segmenttabel die in registers staat gebeurt zeer 
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Figuur 5.29 
Een voorbeeld van segmentering 


snel; het optellen bij de basis en het vergelijken met de limiet kan, om tijd te 
besparen, gelijktijdig plaatsvinden. De PDP-11/45 gebruikt deze benadering; hij 
heeft acht segmentregisters. Een adres van 16 bits is opgebouwd uit een segment- 
nummer van 3 bits en een relatieve positie van 13 bits binnen het segment. Deze 
opzet biedt de mogelijkheid van ten hoogste acht segmenten; elk segment kan 
maximaal 8K bytes lang zijn (zie figuur 5.30). Iedere segmenttabelingang heeft 
een basisadres, een lengte en een groep toegangsbesturingsbits die aangeven of 
er geen toegang, alleen-uitleestoegang of lees-schrijftoegang is voor het segment. 

De Burroughs B5500 bood de mogelijkheid van 32 segmenten, elk van 
maximaal 1024 woorden. Deze specificaties definieerden een segmentnummer 
van 5 bits en een relatieve positie van 10 bits. De ervaring met dit systeem toonde 
evenwel aan dat er te weinig segmenten waren en dat de limiet gesteld aan de 
segmentgrootte te klein was (reeksen van meer dan 1K moesten in verscheidene 
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Figuur 5.30 
Adresbepaling bij segmentering voor de PDP-11/45 


segmenten worden opgebroken). Daarom gaat de GE 645, die gebruikt werd voor 
Multics, tot 256K segmenten van maximaal 64K woorden. 

Met zoveel segmenten is het niet mogelijk de segmenttabel in registers te 
houden, dus moet deze in het geheugen worden gehouden. Een segmenttabel- 
basisregister (STBR) wijst naar de segmenttabel. Omdat het aantal segmenten dat 
door een programma gebruikt wordt sterk kan variëren, wordt ook gebruik ge- 
maakt van een segmenttabel-lengteregister (STLR). Voor een logisch adres (s,d) 
controleren we eerst of het segmentnummer legaal is (s < STLR). Dan tellen we 
het segmentnummer bij het STBR op, waaruit het geheugenadres (STBR + 5) 
van de segmenttabelingang volgt. Deze ingang wordt uit het geheugen gelezen en 
zo gaan we verder als we eerst deden: controleer de relatieve positie aan de hand 
van de segmentlengte en bereken het fysieke adres van het gewenste woord als 
de som van de segmentbasis en de relatieve positie. 

Evenals bij paginering vereist deze vertaling twee geheugenverwijzingen per 
logisch adres, wat neerkomt op een vertraging van het computersysteem met een 
factor twee, tenzij we daar iets aan doen. De normale oplossing is het gebruik 
van een groep associatieve registers om daarin de meest recentelijk gebruikte 
segmenttabelingangen vast te houden. Een betrekkelijk kleine groep associatieve 
registers (8 of 16) kan in het algemeen de vertraging in de toegang tot het geheu- 
gen terugbrengen tot niet meer dan 10 of 15% langzamer dan geheugentoegang 
zonder vertaling. 


5.7.4 Beveiliging en gemeenschappelijk gebruik 


Een bijzonder voordeel van segmentering is het verband dat we kunnen leggen 
tussen segmenten en beveiliging. Aangezien de segmenten een semantisch (naar 
de betekenis) gedefinieerd deel van het programma vormen, zullen alle ingangen 
in het segment waarschijnlijk op dezelfde manier gebruikt worden. Vandaar dat 
we segmenten hebben die instructies zijn, terwijl andere segmenten gegevens 
voorstellen. In een moderne architectuur zijn instructies niet-zichzelf-wijzigend, 
dus instructiesegmenten kunnen als alleen-uitleesbaar of alleen-uitvoerbaar wor- 
den gedefinieerd. De apparatuur voor de adresvertaling zal de beveiligingsbits 
die bij iedere ingang van de segmenttabel horen controleren ter voorkoming van 
illegale toegang tot het geheugen, zoals pogingen om naar een alleen-uitleesbaar 
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segment te schrijven of een alleen-uitvoerbaar segment als gegevens te gebruiken. 
Door een reeks in zijn eigen segment te plaatsen, controleert de apparatuur van 
het geheugenbeheer automatisch of de indices van de reeks legaal zijn en de gren- 
zen van de reeks niet overschrijden. Zo zullen vele veel voorkomende program- 
mafouten door de apparatuur ontdekt worden voordat ze ernstig kwaad kunnen 
aanrichten. 

Een ander voordeel van segmentering heeft te maken met het gemeenschap- 
pelijk gebruik van code of gegevens. Elke job heeft een segmenttabel die bij het 
procesbesturingsblok hoort: het verdeelprogramma gebruikt deze segmenttabel 
om de segmenttabel voor de apparatuur te definiéren wanneer deze job de CVE 
krijgt. Segmenten worden gemeenschappelijk gebruikt wanneer ingangen in de 
segmenttabellen van twee verschillende jobs naar dezelfde fysieke posities wijzen 
(zie figuur 5.31). 

Het gemeenschappelijk gebruik ligt op het segmentniveau. Zo kan een ge- 
meenschappelijk gebruik van informatie worden gemaakt door deze als een seg- 
ment te definiéren. Diverse segmenten kunnen gemeenschappelijk worden ge- 
bruikt, dus een programma dat uit verschillende segmenten is opgebouwd kan 
gemeenschappelijk worden gebruikt. 

Neem bijvoorbeeld het gebruik van een tekstopmaakprogramma in een sys- 
teem met tijddeling. Een volledig opmaakprogramma kan heel groot zijn, samen- 
gesteld uit verschillende segmenten. Deze segmenten kunnen gemeenschappelijk 
worden gebruikt door alle gebruikers, waardoor het fysieke geheugen dat nodig 
is om tekstopmaaktaken te ondersteunen wordt beperkt. In plaats van n maal 
hetzelfde opmaakprogramma hebben we maar één kopie nodig. Voor iedere ge- 
bruiker hebben we nog steeds aparte, unieke segmenten nodig voor de opslag 
van lokale variabelen. Deze segmenten worden natuurlijk niet gemeenschappelijk 
gebruikt. 

Het is ook mogelijk slechts delen van programma’s gemeenschappelijk te 
gebruiken. Veel gebruikte subroutinepakketten kunnen bijvoorbeeld door vele 
gebruikers gemeenschappelijk worden gebruikt door deze te definiëren als ge- 
meenschappelijke, alleen-uitvoerbare segmenten. Twee FORTRAN-program- 
ma’s kunnen bijvoorbeeld van dezelfde Vkw-subroutine gebruik maken, maar er- 
zou dan slechts één kopie van de Vkw-routine nodig zijn. 

Hoewel dit gemeenschappelijk gebruik heel eenvoudig lijkt, zijn er enkele 
overwegingen van subtiele aard. Codesegmenten bevatten gewoonlijk verwijzin- 
gen naar zichzelf. Een voorwaardelijke sprong-instructie bijvoorbeeld heeft een 
overdrachtadres. Het overdrachtadres bestaat uit een segmentnummer en een re- 
latieve positie. Het segmentnummer van het overdrachtadres is het segmentnum- 
mer van het codesegment. Als we proberen dit segment gemeenschappelijk te 
gebruiken, moeten alle daarbij betrokken processen het gemeenschappelijk ge- 
bruikte codesegment zo definiëren dat het altijd hetzelfde segmentnummer heeft. 

Bijvoorbeeld, als we de Vkw-routine gemeenschappelijk willen gebruiken 
en het ene proces wil het segment 4 maken en een ander proces wil het segment 
17 maken, hoe moet dan de Vkw-routine naar zichzelf verwijzen? Omdat er maar 
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één fysieke Vkw-routine is, moet hij voor beide gebruikers op dezelfde manier 
naar zichzelf verwijzen: hij moet een uniek segmentnummer hebben. Met het 
toenemen van het aantal gebruikers die het segment gemeenschappelijk gebrui- 
ken wordt het ook moeilijker een uniek segmentnummer te vinden. 

Alleen-uitleesbare gegevenssegmenten (zonder wijzers) kunnen gemeen- 
schappelijk worden gebruikt als verschillende segmentnummers, evenals codeseg- 
menten die niet direct, maar alleen indirect, naar zichzelf verwijzen. Bijvoorbeeld, 
voorwaardelijke sprongen die het sprongadres specificeren als een relatieve posi- 
tie, gerekend vanaf de programmateller of met betrekking tot een register dat het 
huidige segmentnummer bevat, maken het mogelijk dat de code niet direct ver- 
wijst naar het huidige segmentnummer. 

De GE 645 computer die werd gebruikt voor Multics had vier registers die 
de segmentnummers bevatten van het huidige segment, het stapelsegment, het 
montagesegment en een gegevenssegment. Programma’s verwijzen zelden recht- 
streeks naar een segmentnummer, maar altijd indirect via deze vier segmentregis- 
ters. Hierdoor kan code ongehinderd gemeenschappelijk wordt gebruikt. 


5.7.5 Fragmentatie 


De job-werkindeler moet geheugen vinden en toewijzen voor alle segmenten van 
een gebruikersprogramma. Deze situatie lijkt op die van paginering, behalve dat 
de segmenten een variabele lengte hebben; pagina’s hebben alle dezelfde grootte. 
Derhalve is, evenals dat met MVT het geval is, geheugentoewijzing een probleem 
van het dynamisch toewijzen van opslagruimte, waarvoor de oplossing waar- 
schijnlijk een best-passend- of eerst-passend-algoritme is. 

Segmentering kan dan externe fragmentatie veroorzaken wanneer alle blok- 
ken van het vrije geheugen te klein zijn om een segment te kunnen bergen. In dit 
geval moet de job misschien gewoon wachten tot er meer geheugen (of althans 
een groter gat) beschikbaar komt, of men kan van comprimering gebruik maken 
om grotere gaten te creëren. Aangezien segmentering van nature een dynamisch 
verplaatsingsalgoritme is, kunnen we het geheugen op elk gewenst moment com- 
primeren. Als de CVE-werkindeler moet wachten op een job vanwege een pro- 
bleem met het toewijzen van geheugen, kan het (al of niet) jobs overslaan in de 
CVE-wachtrij om te zien of er een kleinere job met lagere prioriteit kan draaien. 

Hoe ernstig is externe fragmentatie voor een systeem met segmentering? 
Zou job-werkindeling met overslaan van jobs of comprimering helpen? De ant- 
woorden op deze vragen hangen voornamelijk af van de gemiddelde segment- 
grootte. In het ene uiterste geval zouden we elke job kunnen definiëren als één 
segment; deze opzet is MVT. Het andere uiterste is dat elk woord in zijn eigen 
segment gezet en afzonderlijk verplaatst zou kunnen worden. Deze opzet sluit 
externe fragmentatie helemaal uit. Als de gemiddelde segmentgrootte klein is, is 
de externe fragmentatie ook klein. (Bekijk eens de analogie met het zetten van 
koffers in de achterbak van een auto; ze schijnen nooit helemaal te passen. Als 
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je echter de koffers openmaakt en de afzonderlijke dingen in de achterbak doet, 
past alles.) Daar de afzonderlijke segmenten kleiner zijn dan de gehele job, zullen 
zij waarschijnlijk beter in de beschikbare geheugenblokken passen. 


58 Gecombineerde systemen 


Zowel paginering als segmentering hebben hun voor- en nadelen. Het is ook 
mogelijk deze twee manieren te combineren om elk van beide te verbeteren. Deze 
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Gemeenschappelijk gebruik van segmenten in een geheugensysteem met segmentering 


5.8 Gecombineerde systemen 


combinaties worden het best geïllustreerd door twee specifieke systemen: de IBM 
360/67 (en later IBM 370) en de GE 645 voor Multics. 


5.8.1 Gesegmenteerde paginering 


De IBM 360/67 was een van de eerste pagineringssystemen. Het basisadres van 
24 bits werd verdeeld in een paginanummer van 12 bits en een relatieve positie 
van 12 bits. (Programmeurs die bekend zijn met de instructievorm voor de IBM 
360/370 zullen inzien waarom een relatieve positie van 12 bits werd gebruikt.) 
Elke paginatabelingang was 2 bytes (een half woord) die het kadernummer van 
12 bits bevatte en een geldig/ongeldig-bit. Het probleem was dat een paginanum- 
mer van 12 bits 4096 pagina’s toestond, waarbij 8K bytes nodig zijn voor elke 
paginatabel. Bovendien was het gewenst dat het logische adres, met 20 bits voor 
het paginanummer, tot 32 bits werd uitgebreid. Dit zou een paginatabel nodig 
hebben gemaakt van 1.048.576 ingangen, of 2.097.152 bytes. 

In het bijzonder zou, met de grotere adresruimte, het grootste deel van de 
paginatabel leeg geweest zijn, daar de meeste programma’s slechts een fractie van 
de totaal mogelijke adresruimte zouden gebruiken. Daarom was de paginatabel 
gesegmenteerd. De bovenste vier bits van een paginanummer worden als een 
segmentnummer beschouwd, dat wordt gebruikt om één van de zestien ingangen 
van de segmenttabel te selecteren. Ieder segment kan maximaal 268.435.456 bytes 
lang zijn, hoewel zijn lengte een veelvoud van 4096 bytes moet zijn. De ingang 
van de segmenttabel wijst naar de basis van een paginatabel voor dit segment en 
geeft ook de lengte van de paginatabel aan (zie figuur 5.32). Op deze manier 
konden grote secties van de paginatabel die nul waren in elkaar geschoven wor- 
den door het adres van de paginatabel op nul te zetten. 

Natuurlijk vereist deze methode nu in het ergste geval drie geheugentoegan- 
gen per gewenste geheugenverwijzing. Een groep van acht associatieve registers 
brengt de overhead terug tot slechts 150 nanoseconden langzamer dan een verwij- 
zing zonder adresvertaling (750 nanoseconden) bij een treffer. 

Van belang is hier dat de gebruiker nog steeds een lineaire gepagineerde 
adresruimte ziet. Een gevolg van deze opzet is dat het mogelijk is een index op 
te hogen en eerst de laatste positie van segment i te produceren en dan de eerste 
positie van segment i+ 1; het geheugen is nog steeds fundamenteel lineair. 


5.8.2 Gepagineerde segmentering 


Het Multics-systeem kreeg te maken met een ander probleem. Er werden logische 
adressen gevormd uit een segmentnummer van 18 bits en een relatieve positie 
van 16 bits . Hoewel deze methode een 34-bits adresruimte geeft, is de overhead 
van de tabel heel aanvaardbaar, omdat het variabele aantal segmenten uiteraard 
het gebruik van een segmenttabel-lengteregister inhoudt. We hebben slechts zo- 
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Figuur 5.32 
Gesegmenteerde paginering op de IBM 360/67 


veel segmenttabelingangen nodig als we segmenten hebben; er hoeven geen lege 
segmenttabelingangen te zijn. 

Met segmenten van 64K woorden echter zou de gemiddelde segmentgrootte 
heel groot kunnen zijn en zou externe fragmentatie een probleem kunnen vormen. 
Zelfs al is externe fragmentatie geen probleem, dan nog zou de zoektijd om een 
segment toe te wijzen, met behulp van best-passend of eerst-passend, lang kun- 
nen zijn. Zo kunnen we geheugen verspillen wegens externe fragmentatie, of tijd 
verspillen wegens langdurig zoeken, of beide. 

De oplossing die gevonden werd was het pagineren van segmenten. Pagine- 
ring sluit externe fragmentatie uit en maakt van de toewijzing een onbeduidend 
probleem: elk leeg kader kan voor een gewenste pagina worden gebruikt. Het 
resultaat is weergegeven in figuur 5.33. Let op het verschil tussen deze oplossing 
en zuivere segmentering: de ingang van de segmenttabel bevat niet het basisadres 
van het segment, maar het basisadres van een paginatabel voor dit segment. De 


5.8 Gecombineerde systemen 


relatieve positie binnen het segment wordt dan opgedeeld in een paginanummer 
van 6 bits en een relatieve positie binnen de pagina van 10 bits. Het paginanum- 
mer is de index in de paginatabel om het kadernummer te krijgen. Tenslotte 
wordt het kadernummer gecombineerd met de relatieve positie binnen de pagina 
voor het vormen van het fysieke adres. 

Nu moeten we een aparte paginatabel hebben voor ieder segment. Aange- 
zien echter de lengte van ieder segment wordt begrensd door wat in de ingang 
van de segmenttabel is aangegeven, hoeft de paginatabel niet zijn volle lengte te 
hebben. Hij vraagt alleen om zoveel ingangen als er werkelijk nodig zijn. Boven- 
dien zal de laatste pagina van elk segment in het algemeen niet geheel gevuld 
zijn. Zo zullen we gemiddeld een halve pagina interne fragmentatie per segment 
hebben. Dientengevolge hebben we, hoewel we externe fragmentatie hebben uit- 
gebannen, interne fragmentatie ingevoerd en extra tabelruimte toegevoegd. 
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Figuur 5.33 
Gepagineerde segmentering op de GE 645 (Multics) 
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Andere systemen gebruiken ook gepagineerde segmentering. Het Prime 500 
systeem gebruikt een segmentnummer van 12 bits en een relatieve woordpositie 
die gesplitst is in een paginanummer van 6 bits en een relatieve positie binnen 
de pagina van 10 bits. De RCA Spectra 70/46 had een segmentnummer van 5 
bits en een relatieve positie van 18 bits, samengesteld uit een paginanummer van 
6 bits en een relatieve bytepositie van 12 bits. 

Om de waarheid te zeggen, zelfs de zojuist gepresenteerde kijk op Multics 
is simplistisch. Daar het segmentnummer een grootheid van 18 bits is, zouden 
we maximaal 262.144 segmenten kunnen hebben, waarvoor een zeer grote seg- 
menttabel vereist is. Om dit probleem te verlichten pagineert Multics de segment- 
tabel. Dus-in het algemeen gebruikt een adres in Multics het segmentnummer 
om een pagina-index in een paginatabel voor de segmenttabel te definiëren. Uit 
de inhoud van deze ingang wordt het deel van de segmenttabel gelokaliseerd 
dat de ingang voor dit segment bevat. De segmenttabelingang wijst naar een 
paginatabel voor dit segment, die het kader dat het gewenste woord bevat speci- 
ficeert. 


5.9 Samenvatting 


Algoritmen voor het geheugenbeheer voor besturingssystemen met multipro- 
grammering lopen uiteen van de simpele residente-monitor-benadering tot ge- 
pagineerde segmentering. De grootste beslissende factor in het beleid dat in een 
bepaald systeem gevoerd wordt is de apparatuur waarop het systeem draait. Elk 
geheugenadres dat door de CVE wordt gegenereerd moet worden gecontroleerd 
op wettigheid en mogelijk worden vertaald naar een fysiek adres. De controle 
kan niet (efficiënt) in de programmatuur worden geïmplementeerd. Derhalve zijn 
we beperkt door de beschikbare apparatuur. 

De besproken algoritmen voor geheugenbeheer (kale machine, residente 
monitor, MFT, MVT, paginering, segmentering en combinaties van paginering 
en segmentering) verschillen in vele opzichten. De volgende lijst geeft enkele be- 
langrijke overwegingen bij het vergelijken van de verschillende strategieën voor 
geheugenbeheer aan. 


@ Ondersteuning door de apparatuur. Een eenvoudig hekregister of een paar 
grensregisters zijn voldoende voor een residente monitor, MFT of MVT, ter- 
wijl paginering en segmentering vertaaltabellen nodig hebben voor het vastleg- 
gen van de adresvertaling. 

e Het prestatievermogen. Naarmate het algoritme complexer wordt, neemt de 
tijd nodig voor het vertalen van een logisch adres naar een fysiek adres toe. 
Voor de eenvoudige systemen hoeven we alleen te vergelijken, of bij het logi- 
sche adres iets op te tellen, bewerkingen die heel snel zijn. Paginering en seg- 
mentering kunnen net zo snel zijn indien de tabel in snelle registers is geïmple- 
menteerd. Staat de tabel echter in het geheugen, dan kunnen de toegangen tot 
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het gebruikersgeheugen aanzienlijk worden vertraagd. Een groep associatieve 
registers kan de verlaging van het prestatievermogen tot een aanvaardbaar 
niveau terugbrengen. 

@ Fragmentatie. Een systeem met multiprogrammering zal in het algemeen een 
betere prestatie leveren naarmate het multiprogrammeringsniveau hoger is. 
Voor een gegeven groep van jobs kan het multiprogrammeringsniveau alleen 
worden verhoogd door meer jobs in het geheugen te proppen. Om dit te kun- 
nen doen moeten we de geheugenverspilling, ofwel fragmentatie, verminderen. 
Systemen met toewijzingseenheden met een vaste grootte, zoals MFT of pa- 
ginering, hebben last van interne fragmentatie; systemen met toewijzingseen- 
heden met een veranderlijke grootte, zoals MVT en segmentering, hebben last 
van externe fragmentatie. 

@ Verplaatsing. Eén oplossing voor het probleem van externe fragmentatie is 
comprimering. Comprimering houdt in het verplaatsen van een programma 
in het geheugen zonder dat het programma deze verandering bemerkt. Deze 
overweging houdt de eis in dat logische adressen dynamisch worden verplaatst 
ten tijde van de uitvoering. Als adressen alleen ten tijde van het laden ver- 
plaatst worden, kunnen we het geheugen niet comprimeren. 

@ Programmaverwisseling. Aan elk algoritme kan programmaverwisseling wor- 
den toegevoegd. Met tussenpozen, die bepaald worden door het besturingssys- 
teem en die gewoonlijk worden opgelegd door het beleid inzake CVE-werkin- 
deling, worden jobs uit het interne geheugen naar een extern geheugen ge- 
kopieerd en later teruggekopieerd naar het interne geheugen. Deze opzet biedt 
de mogelijkheid meer jobs te draaien dan er gelijktijdig in het geheugen kun- 
nen. | 

@ Gemeenschappelijk gebruik. Een andere manier om het multiprogrammerings- 
niveau te verhogen bestaat in het gemeenschappelijk gebruik van code en gege- 
vens door verschillende gebruikers. Dit vereist in het algemeen dat paginering 
of segmentering wordt gebruikt, om kleine informatiepakketjes te verschaffen 
(pagina’s of segmenten) die gemeenschappelijk kunnen worden gebruikt. Het 
gemeenschappelijk gebruik is een middel om met een beperkte hoeveelheid 
geheugen vele gebruikers te laten draaien; maar programma’s en gegevens voor 
gemeenschappelijk gebruik moeten zorgvuldig worden ontworpen. 

e Beveiliging. Bij paginering of segmentering kunnen verschillende gedeelten 
van een gebruikersprogramma als alleen-uitvoerbaar, als alleen-uitleesbaar, of 
met lees-schrijftoegang worden gedeclareerd. Deze beperking is noodzakelijk 
bij gemeenschappelijk gebruik van code of gegevens, en in het algemeen in elk 
geval nuttig om tijdens het draaien eenvoudige controles op veel voorkomende 
programmeerfouten te kunnen uitvoeren. 
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Opgaven 


5.1 


5.2 


5.3 


5.4 


5.5 
5.6 


5.7 


Verklaar de volgende algoritmen voor toewijzing: 
a. Eerst-passend. 

b. Best-passend. 

c. Slechtst-passend. 


Wanneer een job uit het geheugen weggeschreven wordt (rolled out), 
verliest hij de mogelijkheid (althans gedurende enige tijd) de CVE te 
gebruiken. Noem een andere situatie waarin een job de mogelijkheid de 
CVE te gebruiken verliest, maar waarin hij niet uit het geheugen wordt 
weggeschreven. 


Neem het geval van een logische adresruimte van 8 pagina’s van 1024 
woorden, die wordt vertaald naar een fysiek geheugen van 32 kaders. 
a. Uit hoeveel bits bestaat het logische adres? 

b. Uit hoeveel bits bestaat het fysieke adres? 


Neem een pagineringssysteem met een paginagrootte van 100 woorden. 
Noem voor het volgende programma in de assembleertaal (beginnend 
op positie 0) de reeks van geheugenadressen waar het programma komt. 
(Beschouw zowel gegevens- als instructieadressen.) 

. Laad vanuit 263. 

. Berg op in 264. 

. Berg op in 265. 

. Lees van randapparaat. 

. Spring naar positie 4 als randapparaat bezig. 

. Berg op in 901. 

. Laad vanuit 902. 

. Stop. 


JAREN 


Verklaar het verschil tussen logische en fysieke adressen. 


Beschouw een systeem met paginering waarbij de paginatabel in het ge- 

heugen staat. 

a. Als een geheugenverwijzing 1,2 microseconden duurt, hoe lang duurt 
dan een gepagineerde geheugenverwijzing? 

b. Als we acht associatieve registers toevoegen en 75% van alle verwijzin- 
gen naar de paginatabel in de associatieve registers worden gevonden, 
wat is dan de effectieve geheugentoegangstijd? (Neem aan dat het 
vinden van een paginatabelingang, als die daarin aanwezig is, geen 
tijd in beslag neemt.) 


Waarom kon OS/MVT op de IBM 360 niet comprimeren? Hoe werd dit 
probleem op de CDC 6600 opgelost om comprimering wél mogelijk te 
maken? 
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5.8 
5.9 


5.10 


5.11 


5.12 


5.13 


Verklaar het verschil tussen interne en externe fragmentatie. 


Beschrijf de apparatuur die nodig is om paginering te ondersteunen met 
een aanvaardbare hoeveelheid overhead. 


Op de IBM/360 zijn de pagina’s 4096 bytes lang. Daar adressen 24 bits 
lang zijn, betekent dit dat er 4096 pagina’s in het logische geheugen kun- 
nen zijn, hetgeen een paginatabel vereist van 4096 ingangen. Omdat elke 
paginatabelingang twee bytes in beslag neemt, zijn er alleen al twee pa- 
gina’s van het geheugen nodig om de paginatabel kwijt te kunnen. Als 
we aannemen dat processen geheugenadressen gebruiken van 0 tot m en 
geen adressen gebruiken van m+1 tot 16.777.215 (274 — 1), geef dan 
aan hoe u de normale apparatuur voor paginering zou wijzigen zodat de 
gemiddelde grootte van de paginatabellen afneemt. 

Neem nu de situatie dat programma’s bij voorkeur een groep op- 
eenvolgende geheugenblokken adresseren (van a tot b, van c tot d, van e 
tot f, enzovoort), maar niet de gebieden tussen de blokken (van b tot c, 
d tot e, f tot g, enzovoort). Dit zou het gevolg kunnen zijn van program- 
ma’s die hun reeksen of matrices met de maximale grenzen declareren 
(verscheidene duizenden posities), maar slechts (gemiddeld) de eerste 
paar elementen gebruiken. Definieer een nieuwe structuur voor de pa- 
ginatabel en bijbehorende methode voor adresvertaling om de pagina- 
tabellen voor deze situatie klein te houden. 


De meeste machines hebben geen apparatuur voor paginering of seg- 
mentering. Als een probleem een zeer grote adresruimte nodig heeft, kan 
een van beide methoden dan worden geimplementeerd in de program- 
matuur? Schets hoe. Wat zou gemakkelijker zijn, paginering of segmen- 
tering? 


Stel dat we een systeem voor gepagineerd geheugen hebben met associa- 
tieve registers voor het vasthouden van de meest actieve paginatabelin- 
gangen. Als de paginatabel gewoonlijk in het geheugen staat en de geheu- 
gentoegangstijd 1 microseconde is, wat is dan de effectieve toegangstijd 
als 85% van alle geheugenverwijzingen hun ingangen in de associatieve 
registers vinden? Wat is de effectieve toegangstijd als de trefkans van de 
associatieve registers slechts 50% is? 


Wat is het effect als we twee ingangen in een paginatabel naar hetzelfde 
paginakader in het geheugen laten wijzen? Zou dit kunnen worden ge- 
bruikt om de hoeveelheid tijd, nodig voor het kopiéren van een grote 
hoeveelheid geheugen van de ene plaats naar de andere, terug te bren- 
gen? Wat zou het effect zijn van het opslaan van de ene pagina in de 
andere? 
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5.14 We hebben de volgende segmenttabel: 


5.15 


5.16 


5.17 


5.18 


Segment Basis Lengte 


0 219 600 
l 2300 14 
2 90 100 
3 1327 580 
4 1952 96 


Wat zijn de fysieke adressen voor de volgende logische adressen? 
a. 0,430 

b. 1,10 

Gi 1,1} 

d. 2,500 

e. 3,400 

f. 4,112 


Waarom worden segmentering en paginering soms tot één methode ge- 
combineerd? 


Leg uit waarom het gemeenschappelijk gebruik maken van een herbe- 
treedbare module gemakkelijker is met segmentering dan met zuiver pa- 
gineren. 


Beschrijf een mechanisme waardoor één segment tot de adresruimten 
van twee verschillende processen zou kunnen behoren. 


Beschouw een systeem met tijddeling en programmaverwisseling, met 
één trommel voor programmaverwisseling en drie vaste regio’s in het 
geheugen. De gemiddelde wachttijd voor de trommel bedraagt vier mil- 
liseconden; de overbrengtijd voor één regio is zes milliseconden. Nu wil- 
len we programmaverwisseling doen voor één regio terwijl de processen 
in de andere twee doorgaan met hun verwerking. Een job wordt alleen 
verwisseld en op de trommel gezet wanneer hij moet wachten op invoer 
van zijn gebruiker; hij wordt weer in het geheugen teruggebracht wan- 
neer er een regio vrij is en er een invoerregel van zijn gebruiker is. 

a. Als dit een ideale wereld was, zouden we mogen hopen een ge- 
bruiksfactor van 100% te realiseren voor de CVE en de schijf (beide 
altijd bezig). Hoe lang moet, om een gebruiksfactor van 100% te ha- 
len, een job een invoerregel verwerken voordat hij op de volgende 
regel moet wachten? 

b. Als gebruikers elke seconde één te verwerken regel invoeren, wat is 
dan het maximale aantal gebruikers dat kan worden bediend? 
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5.19 


5.20 


5.21 


In de IBM/360 komt geheugenbeveiliging tot stand met behulp van sleu- 
tels. Een sleutel is een grootheid van 4 bits. Elk geheugenblok van 2048 
bytes heeft een bijbehorende sleutel (de geheugensleutel). De CVE heeft 
eveneens een bijbehorende sleutel (de beveiligingssleutel). Een opberg- 
bewerking mag alleen plaatsvinden als beide sleutels gelijk zijn, of één 
van beide nul is. Welk van de volgende methoden voor geheugenbeheer 
zou op deze apparatuur met succes kunnen worden gebruikt? 

. Kale machine. 

. Residente monitor. 

Multiprogrammering met een vast aantal processen. 

. Multiprogrammering met een variabel aantal processen. 

Paginering. 

Segmentering. 


=o AO op 


Beschouw een machine met een verplaatsingsregister en een limietregis- 
ter (zoals de CDC 6600). We willen graag een besturingssysteem schrij- 
ven dat vele gebruikers voorziet van een BASIC-vertolker en -tekstop- 
maakprogramma onder tijddeling. Er zullen geen gebruikersprogram- 
ma’s worden gecompileerd; BASIC-programma’s zullen alleen worden 
vertolkt. In andere talen wordt niet voorzien. Gebruikers zullen in staat 
zijn in te voeren vanaf hun terminals en uit te voeren naar hun terminals 
en naar schijfbestanden. We hebben 100K geheugen, en de code van de 
BASIC-vertolker neemt ongeveer 15K in beslag. We hebben ook vier 
schijven met bewegende lees/schrijfkoppen. 

Het BASIC-programma dat vertolkt wordt zal in het geheugen 
worden opgeslagen als gecomprimeerde tekst en kan vector- en matrix- 
structuren declareren, zodat de hoeveelheid geheugen voor elke gebrui- 
ker 15K bedraagt plus opslagruimte voor de programmatekst en voor 
gegevens. Bespreek hoe het systeem geheugen zou moeten toewijzen. 


De mogelijkheid processen gemeenschappelijk gebruik te laten maken 
van segmenten, zonder de eis dat deze hetzelfde segmentnummer heb- 
ben, is voorhanden in een dynamisch aaneengeschakeld segmenterings- 
systeem. 

a. Definieer een systeem dat de mogelijkheid biedt van statische aaneen- 
schakeling en gemeenschappelijk gebruik van segmenten, zonder dat 
het nodig is dat deze dezelfde segmentnummers hebben. 

b. Geef een pagineringsmethode die de mogelijkheid biedt van gemeen- 
schappelijk gebruik van pagina’s, zonder dat daarvoor dezelfde pa- 
ginanummers nodig zijn (voor paginering op verzoek; Engels: de- 


mand paging). 
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Bibliografische verwijzingen 


Externe en interne fragmentatie worden besproken door Randell [1969]. 

De methode voor toewijzing van vaste partities wordt gebruikt in IBM OS/ 
360 MFT (Multiprogrammering met een vast aantal taken). De methode voor 
toewijzing van variabele partities wordt gebruikt in IBM OS/360 MVT (Multi- 
programmering met een variabel aantal taken). Besprekingen van beide soorten 
systemen worden gegeven door Knight [1968], Madnick en Donovan [1974, para- 
graaf 3.3] en Hoare en McKeag [1972]. 

Het begrip paginering komt op naam van de ontwerpers van het Atlas- 
systeem [Kilburn et al. 1961, 1962]. Een pagineringssysteem uit de begintijd is de 
XDS-940; het wordt beschreven door Lichtenberger en Pirtle [1965] en Lampson 
et al. [1966]. 

Het begrip segmentering werd het eerst besproken door Dennis [1965]. On- 
der de systemen die aaneengesloten toewijzing per segment gebruiken bevinden 
zich de Burroughs B5700, B6500 en B7600 computersystemen, waarin adresver- 
taling plaatsvindt in de apparatuur [Organick 1973] en het PDP-11/45 computer- 
systeem. 

Systemen die gebruik maken van paginering met segmentering zijn onder 
andere de GE 645, waarop Multics oorspronkelijk werd geimplementeerd [Or- 
ganick 1972], het IBM 360/67 systeem [Comfort 1965], en de RCA Spectra 70/ 
46 [Oppenheimer en Weizer 1968]. 


6 


VIRTUEEL GEHEUGEN 


In het vorige hoofdstuk hebben we diverse strategieën voor geheugenbeheer be- 
sproken die in computersystemen zijn gebruikt. Al deze strategieën hebben het- 
zelfde doel: veel processen gelijktijdig in het geheugen te houden om van multi- 
programmering gebruik te kunnen maken. Zij vereisen evenwel dat het gehele 
proces in het geheugen is opgenomen voordat het kan worden uitgevoerd. 

Virtueel geheugen is een techniek die het mogelijk maakt dat processen 
worden uitgevoerd die niet geheel in het geheugen zijn. Het belangrijkste en meest 
in het oog lopende voordeel van deze opzet is dat gebruikersprogramma’s groter 
kunnen zijn dan het fysieke geheugen. Het is echter niet gemakkelijk om virtueel 
geheugen te implementeren en het kan, als het niet met zorg wordt gebruikt, 
het prestatievermogen aanzienlijk verslechteren. In dit hoofdstuk bespreken we 
virtueel geheugen in de vorm van pagineren op verzoek en onderzoeken we de 
complexiteit en de kosten ervan. 


6.1 Overlappende programmasegmenten (overlays) 


De algoritmen voor geheugenbeheer van hoofdstuk 5 zijn noodzakelijk wegens 
één fundamentele eis: de gehele logische adresruimte van een proces moet in het 
fysieke geheugen zijn opgenomen voordat een proces kan worden uitgevoerd. 
Deze beperking schijnt zowel noodzakelijk als redelijk te zijn, maar hij is ook 
ongunstig, omdat daardoor de omvang van een programma beperkt wordt tot de 
omvang van het fysieke geheugen. 

In feite toont een onderzoek van bestaande programma’s aan dat in veel 
gevallen niet het hele programma nodig is. Bijvoorbeeld: 


@ Programma's hebben vaak code voor het behandelen van ongewone foutcon- 
dities. Aangezien deze fouten zelden of nooit in de praktijk voorkomen, wordt 
deze code bijna nooit uitgevoerd. 

@ Aan reeksen (eendimensionale arrays), matrices (tweedimensionale arrays), 
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lijsten en tabellen wordt vaak meer geheugen toegewezen dan zij in werkelijk- 
heid nodig hebben. Er kan wel een matrix van 100 bij 100 gedeclareerd zijn, 
ook al is deze zelden groter dan 10 bij 10. De symbolentabel van een assem- 
bleerprogramma kan ruimte hebben voor 3000 symbolen, hoewel het gemid- 
delde programma minder dan 200 symbolen telt. 

e Het kan zijn dat zekere opties en voorzieningen van een programma zelden 
worden gebruikt, zoals het commando van een tekstopmaakprogramma om 
van alle tekens binnen een gebied van een aantal regels hoofdletters’ te maken. 


Zelfs in die gevallen waarin het hele programma nodig is, hoeft niet alles op 
hetzelfde ogenblik nodig te zijn. 

Als we een programma konden uitvoeren dat slechts voor een deel in het 
geheugen staat, zou dat veel voordelen hebben: 


@ Een programma zou niet langer beperkt worden door de hoeveelheid fysiek 
geheugen die beschikbaar is. Gebruikers zouden programma’s kunnen schrij- 
ven voor een zeer grote virtuele adresruimte, wat de taak van het programme- 
ren zou vereenvoudigen. 

@ Daar iedere gebruiker minder fysiek geheugen in beslag zou nemen, kunnen 
meer gebruikers tegelijk hun programma’s draaien, waarbij de CVE-ge- 
bruiksfactor en de doorvoercapaciteit evenredig zouden toenemen, zonder dat 
echter de responstijd of turnaround-tijd toenemen. 

@ Er zou minder I/O nodig zijn voor het laden of verwisselen van elk gebruikers- 
programma, zodat iedere gebruiker zijn programma’s sneller zou kunnen 
draaien. 


Zo zouden zowel het systeem als de gebruiker gebaat zijn bij het draaien van een 
programma dat zich niet geheel in het geheugen bevindt. 

Een techniek van overlappende programmasegmenten, die gewoonlijk met 
het Engelse woord overlays wordt aangeduid, wordt soms gebruikt om een pro- 
gramma te draaien dat groter is dan de hoeveelheid geheugen die eraan is toe- 
gewezen. De gedachte achter overlays is alleen die instructies en gegevens in het 
geheugen te houden die op elk moment nodig zijn. Wanneer andere instructies 
nodig zijn, worden deze in de ruimte geladen die voordien bezet was door instruc- 
ties die niet langer nodig zijn. 

Om een voorbeeld te geven, neem het geval van een assembleerprogramma 
met twee doorgangen. Gedurende doorgang 1 zet het programma een symbolen- 
tabel op en genereert vervolgens tijdens doorgang 2 de code in de machinetaal. 
Misschien zijn we in staat zo’n assembleerprogramma in stukken te verdelen: de 
code voor doorgang 1, de code voor doorgang 2, de symbolentabel, en gemeen- 
schappelijke ondersteuningsroutines die zowel door doorgang | als door door- 
gang 2 gebruikt worden. Stel dat de grootte van deze componenten bedraagt: 


6.1 Overlappende programmasegmenten (overlays) 


Doorgang 1 18K 
Doorgang 2 210K 
Symbolentabel 14K 


Gemeenschappelijke routines 5K 


Om alles tegelijk te laden is 37K geheugen nodig. Als slechts 32K beschikbaar is 
kunnen we ons programma niet draaien. Bedenk evenwel dat doorgang 1 en door- 
gang 2 niet gelijktijdig in het geheugen hoeven te zijn. Daarom definiëren we twee 
overlays: (A) de symbolentabel, de gemeenschappelijke routines en doorgang 1, 
en (B) de symbolentabel, de gemeenschappelijke routines en doorgang 2. 

We voegen een overlay-stuurprogramma (2K) toe en beginnen met overlay 
A in het geheugen. Bij het beëindigen van doorgang 1 springen we naar het over- 
lay-stuurprogramma, dat overlay B in het geheugen laadt, waarbij overlay A 
wordt overschreven, en dan de besturing overdraagt aan doorgang 2. Overlay A 
heeft slechts 29K geheugen nodig, terwijl overlay B 31K nodig heeft (zie figuur 
6.1). We kunnen ons assembleerprogramma nu in de 32K beschikbaar geheugen 
draaien. Het zal echter wat langzamer draaien, wegens de extra I/O die nodig is 


symbolen- 
tabel 


14K 


gemeenschappelijke 
routines 


stuurprogramma 
voor ‘overlays’ 


SK 


8K 


doorgang 1 10K 


Figuur 6.1 
Overlappende programmasegmenten (‘overlays’) voor een assembleerprogramma met twee 
doorgangen 
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om de code voor overlay B over de code voor overlay A heen te lezen. 

De code voor overlay A en de code voor overlay B worden op schijf of 
magneetband bewaard als absolute geheugenbeelden, die door het overlay-stuur- 
programma, al naar dit nodig is, worden gelezen. Voor het opzetten van de over- 
lays zijn speciale verplaatsings- en montage-algoritmen nodig. 

Een onderwerp dat hiermee verband houdt is dynamisch laden. Bij dy- 
namisch laden wordt een routine niet geladen totdat deze aangeroepen wordt. 
Alle routines worden op schijf bewaard in verplaatsbaar laadformaat. Het hoofd- 
programma wordt in het geheugen geladen en uitgevoerd. Wanneer een routine 
een andere routine wil aanroepen, controleert de aanroepende routine eerst of 
de andere routine geladen is. Zo niet, dan wordt het verplaatsbare montage- en 
laadprogramma aangeroepen om de gewenste routine te laden en de tabellen bij 
te werken om deze verandering weer te geven. Dan wordt de besturing overgedra- 
gen aan de zojuist geladen routine. Het voordeel van dynamisch laden is dat een 
niet-gebruikte routine nooit wordt geladen. Deze opzet is bijzonder nuttig wan- 
neer grote hoeveelheden code nodig zijn om weinig voorkomende gevallen te 
behandelen, zoals diverse foutroutines. In dit geval kan, hoewel het totale pro- 
gramma groot kan zijn, het gedeelte dat echt gebruikt (en dus werkelijk geladen) 
wordt veel kleiner zijn. 

‘Noch overlays noch dynamisch laden hebben speciale ondersteuning door 
het besturingssysteem nodig. Beide kunnen volledig door de gebruiker zelf met 
eenvoudige bestandsstructuren worden geïmplementeerd. Daarbij wordt van de 
bestanden in het geheugen gelezen en wordt naar dat geheugengedeelte gespron- 
gen om de zojuist ingelezen instructies uit te voeren. Het besturingssysteem merkt 
slechts dat er meer 1/O is dan gewoonlijk. 

Daar staat tegenover dat de gebruiker/ programmeur de overlay-structuur 
goed moet ontwerpen en programmeren. Dit kan een lastig karwei zijn, waarbij 
volledige kennis van de structuur van het programma, de programmacode en de 
gegevensstrueturen vereist is. Omdat het programma per definitie zeer groot is 
(kleine programma’s hoeven niet met overlays te werken), kan voldoende begrip 
van het programma heel moeilijk zijn. Automatische technieken voor het draaien 
van grote programma’s in beperkte hoeveelheden fysiek geheugen verdienen 
daarom de voorkeur. 


6.2 Pagineren op verzoek 


Virtueel geheugen is de omschrijving voor een stel technieken die het ons mogelijk 
maken een programma uit te voeren dat zich niet geheel in het geheugen bevindt. 
Pagineren op verzoek is het meest voorkomende systeem voor virtueel geheugen. 

Pagineren op verzoek lijkt op een pagineringssysteem met programmaver- 
wisseling (zie figuur 6.2). Op een randapparaat voor programmaverwisseling, het 
hulpgeheugen of het externe heugen (Engels: backing store), staan programma’s. 
Wanneer we een programma willen uitvoeren brengen we het in het geheugen. 


6.2 Pagineren op verzoek 


zet uit 
het 
geheugen 


programma A 
120 ti Jia Jas{ | 
EERE pH 
programma B geheugen 
20[ Jai a ]23[ | 
intern geheugen 
Figuur 6.2 


Het overbrengen van een in pagina's verdeeld geheugen naar en van een aaneengesloten 
schijfruimte 


In plaats van het hele programma in het geheugen te brengen, gebruiken we 
echter een ’luie’ programmaverwisselaar. De luie programmaverwisselaar brengt 
uitsluitend een pagina in het geheugen als deze nodig is. Er zijn veel voordelen 
verbonden aan het gebruik van een luie programmaverwisselaar. Dit brengt de 
tijd nodig voor programmaverwisseling terug, en ook de hoeveelheid benodigd 
geheugen, waardoor een hoger multiprogrammeringsniveau mogelijk wordt. 

Maar wat gebeurt er wanneer het programma probeert een pagina te gebrui- 
ken die niet in het geheugen werd gebracht? De apparatuur zal proberen het 
adres van de gebruiker te vertalen in een fysiek adres door gebruik te maken van 
de paginatabel. 

Hoe ziet de ingang in de paginatabel eruit voor een pagina die niet in het 
geheugen gebracht is? Er is geen bijbehorend paginakader; de toegang moet dus 
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ongeldig zijn. We kunnen de toegangspoging verijdelen door voor die pagina's 
die niet in het geheugen gebracht zijn de geldig/ongeldig-bit in de paginatabel 
op ongeldig te zetten (zie figuur 6.3). 

Merk op dat dit ongeldig maken geen effect zal hebben als het programma 
nooit probeert tot die pagina toegang te verkrijgen. Vandaar dat als we goed 
gokken en alleen die pagina’s in het geheugen brengen die werkelijk nodig zijn, 
het programma precies zo zal draaien alsof we alle pagina’s in het geheugen had- 
den gebracht. 
| Gokken we echter verkeerd en probeert het programma toegang te krijgen 
tot een pagina die niet in het geheugen gebracht werd, dan zal een paginafout 
optreden. 

Het pagineringsmechanisme zal bij het vertalen van het adres via de pagina- 
tabel in de gaten hebben dat de ongeldig-bit aanstaat, waardoor een val’ naar het 
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Paginatabel wanneer sommige pagina’s zich niet in het interne geheugen bevinden 


6.2 Pagineren op verzoek 


besturingssysteem opengaat ("ongeldig adres’-fout). Gewoonlijk is een ’ongeldig 
adres’-fout het resultaat van een poging om een illegaal geheugenadres te gebrui- 
ken (zoals een incorrecte index voor een reeks). In zo’n geval moet het program- 
ma worden beëindigd. In dit geval echter is het in het geheugen brengen van een 
geldig gedeelte van het programma door het besturingssysteem mislukt, waardoor 
de ‘val’ zal opengaan, als gevolg van de poging de overhead van programmaver- 
wisseling en de geheugenbehoeften te minimaliseren. We moeten deze tekort- 
koming daarom corrigeren. De procedure is heel eenvoudig (zie figuur 6.4). 
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Figuur 6.4 
Stappen bij de behandeling van een paginafout 
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1. Eerst gaan we in een interne tabel, die samen met het procesbesturingsblok 
voor dit proces wordt bijgehouden, na of de geheugenverwijzing een geldige 
of ongeldige geheugentoegang was. Was deze ongeldig, dan beëindigen we het 
programma. 

2. Was het een geldige verwijzing, maar hebben we de desbetreffende pagina nog 
niet in het geheugen gebracht, dan moeten we deze nu binnenbrengen. 

3. Zoek een vrij kader op (bijvoorbeeld door er één van de vrije-kaderlijst te 
nemen). 

4. Zet een schijfbewerking op om de gewenste pagina in het zojuist toegewezen 
kader in te lezen. 

5. Wijzig, zodra de schijfbewerking klaar is, de interne tabel die bij het proces 

en paginatabel hoort, om aan te geven dat de pagina nu in het geheugen. is. 

6. Start de instructie, die werd onderbroken door de ’ongeldig adres’-val, op- 
nieuw. Het proces kan nu toegang krijgen tot de pagina alsof deze altijd in 
het geheugen was geweest. 


Het is van belang te beseffen dat we, door het opslaan van de toestand 
(registers, resultaatcode, programmateller) van het onderbroken proces op het 
moment dat het in de ’ongeldig adres’-val loopt, het proces op precies dezelfde 
plaats en in dezelfde toestand opnieuw kunnen starten, behalve dan dat de ge- 
wenste pagina nu in het geheugen en toegankelijk is. Op deze wijze zijn we in 
staat een programma uit te voeren, ook al zijn gedeelten daarvan (nog) niet in 
het geheugen. Wanneer het proces probeert toegang te verkrijgen tot zekere po- 
sities die niet in het geheugen zijn, loopt het in de ’val’ van de apparatuur naar 
het besturingssysteem (paginafout). Het besturingssysteem leest de gewenste pa- 
gina in het geheugen in en start het proces opnieuw alsof de pagina altijd in het 
geheugen was geweest. 

In het uiterste geval zouden we aan de uitvoering van het proces kunnen 
beginnen zonder één enkele pagina in het geheugen. Het proces zou onmiddellijk 
bij de eerste instructie een paginafout veroorzaken. Na het binnenbrengen van 
de pagina in het geheugen zou het proces met de uitvoering verder gaan en steeds 
wanneer dit nodig is een paginafout veroorzaken, totdat elke pagina die het nodig 
heeft in het geheugen zou zijn. Op dat punt aangekomen zou het zonder verdere 
paginafouten kunnen worden uitgevoerd. Dit is zuiver pagineren op verzoek: breng 
_ dan pas een pagina in het geheugen als deze nodig is. 

De apparatuur ter ondersteuning van pagineren op verzoek is dezelfde als 
de apparatuur voor paginering en programmaverwisseling: 


@ Een paginatabel met de mogelijkheid een ingang als ongeldig te markeren, door 
middel van een geldig/ongeldig-bit of een speciale waarde van beveiligingsbits. 

@ Een extern geheugen voor de opslag van die pagina’s die niet in het hoofdge- 
heugen zijn opgenomen. Het externe geheugen is gewoonlijk een zeer snelle 
schijf of trommel of massa-kernengeheugen, zoals het ECS (Extended Core 
Storage) van IBM. 


6.2 Pagineren op verzoek 


Naast deze ondersteuning door de apparatuur is, zoals we zullen zien, een aan- 
zienlijke hoeveelheid programmatuur nodig. 

Aan de architectuur moeten nog enkele extra beperkingen worden opge- 
legd. Een cruciale kwestie is de noodzaak iedere instructie na een paginafout 
opnieuw te kunnen starten. In veel gevallen kan aan deze eis gemakkelijk worden 
voldaan. Een paginafout zou bij elke geheugenverwijzing kunnen optreden. Als 
de paginafout plaatsvindt bij het ophalen van de instructie, kunnen we opnieuw 
starten door de instructie opnieuw op te halen. Als de paginafout optreedt bij 
het ophalen van een operand, moeten we de instructie opnieuw ophalen, deze 
opnieuw decoderen en dan de operand ophalen. 

Laten we eens kijken naar, als een soort ongunstigste geval, een instructie 
met drie adressen, zoals TEL A OP bij B, waarbij het resultaat in C wordt gezet. 
De achtereenvolgende stappen voor het uitvoeren van deze instructie zijn: 


1. Haal de instructie (TEL OP) op en decodeer deze. 
2. Haal A op. 

3. Haal B op. 

4. Tel op. 

5. Berg de som op in C. 


Als de paginafout zou optreden wanneer we in C probeerden op te bergen (omdat 
C in een pagina voorkomt die op dit moment niet in het geheugen is), zouden we 
de gewenste pagina moeten opzoeken, deze in het geheugen brengen, de pagina- 
tabel bijwerken en de instructie opnieuw starten. Hiervoor is nodig dat de in- 
structie opnieuw wordt opgehaald, opnieuw wordt gedecodeerd, dat de twee 
operanden weer worden opgehaald en dat dan de optelling weer plaatsvindt. Er 
moet echter niet echt veel werk worden overgedaan (minder dan 1 volledige in- 
structie), en dit is dan nog alleen nodig wanneer een paginafout optreedt. 

De belangrijkste moeilijkheid treedt op wanneer één instructie verschillen- 
de geheugenposities kan wijzigen. Neem bijvoorbeeld de MVC-instructie (move 
character, breng teken over) op de IBM 370. Deze instructie kan maximaal 256 
bytes van de ene naar een andere positie (mogelijk met overlappende delen) over- 
brengen. Als één van beide blokken (bron of bestemming) over een paginagrens 
heen komt, kan een paginafout optreden nadat de overbrenging gedeeltelijk vol- 
tooid is. Bovendien kan het gebeuren, als het bron- en bestemmingsblok elkaar 
gedeeltelijk overlappen, dat het bronblok al gewijzigd is, in welk geval we niet 
zomaar de instructie opnieuw kunnen beginnen. | 

Dit probleem kan, afhankelijk van het model dat we kiezen, op twee manie- 
ren worden opgelost. In de ene oplossing zal de microcode de posities van beide 
uiteinden van beide blokken berekenen en proberen hiertoe toegang te verkrijgen. 
Treedt er een paginafout op, dan zal deze plaatsvinden tijdens deze stap, voordat 
er ook maar iets gewijzigd is. De overbrenging kan daarna plaatsvinden in de 
wetenschap dat er geen paginafout kan optreden, omdat alle betrokken pagina’s 
in het geheugen zijn. De andere oplossing maakt gebruik van tijdelijke registers 
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om de waarden van de overschreven posities te bewaren. Treedt er een paginafout 
op, dan worden al de oude waarden naar het geheugen teruggeschreven voordat 
de ’val’ opengaat. Deze handeling brengt het geheugen terug in de toestand die 
het had vóór de instructie was gestart, zodat de instructie kan worden herhaald. 

Een soortgelijk architectureel probleem doet zich voor in de PDP-11, die 
speciale adresseer-modi gebruikt, waaronder automatische ophoging en automa- 
tische verlaging. Deze adresseer-modi gebruiken een register als wijzer en verho- 
gen of verlagen automatisch de registerinhoud, al naar dit nodig is. Bij automati- 
sche verlaging wordt de registerinhoud automatisch verlaagd voordat deze als het 
operand-adres wordt gebruikt. Bij automatische ophoging wordt de registerin- 
houd automatisch opgehoogd nadat deze als het operand-adres is gebruikt. Zo 
kopieert de instructie 


MOV (R2)+,—(R3) 


de inhoud van de positie die wordt aangewezen door register 2 naar de positie 
aangewezen door register 3. Register 2 wordt opgehoogd (met twee voor een 
woord, omdat de PDP-11 een byte-adresseerbare computer is) nadat het als wij- 
zer gebruikt is; register 3 wordt verlaagd (met twee) voordat het als wijzer ge- 
bruikt wordt. Ga nu na wat er gebeurt als we een paginafout krijgen wanneer we 
een teken proberen op te slaan in de positie die door register 3 wordt aangewezen. 
Om de instructie opnieuw te beginnen moeten we in de twee registers de waarden 
terugzetten die ze hadden voordat we met de uitvoering van de instructie begon- 
nen. In de PDP-11/45 en 11/70 werd een speciaal register (SR1: Status-Register 
1) gemaakt om het registernummer en het aantal gewijzigde posities vast te leggen 
voor elk register dat tijdens de uitvoering van een instructie gewijzigd wordt. Dit 
register geeft het besturingssysteem de mogelijkheid de effecten van een gedeelte- 
lijk uitgevoerde instructie die een paginafout veroorzaakt ongedaan te maken. 

Dit zijn zeker niet de enige architecturele problemen die ontstaan als gevolg 
van het aan een bestaande architectuur toevoegen van paginering om pagineren 
op verzoek toe te staan. Maar zij illustreren enkele van de moeilijkheden. Pagine- 
ring wordt in een computersysteem toegevoegd tussen de CVE en het geheugen. 
Voor het gebruikersprogramma moet dit volkomen doorzichtig zijn. Daarom 
wordt er dikwijls van uitgegaan dat paginering aan elk systeem zou kunnen wor- 
den toegevoegd. Hoewel deze veronderstelling juist is voor paginering voor ver- 
plaatsing, waarbij een paginafout een fatale fout is, is deze veronderstelling niet 
juist wanneer een paginafout alleen maar betekent dat een extra pagina in het 
geheugen moet worden gebracht en het programma opnieuw moet worden ge- 
start. 


6.3 Prestatievermogen van pagineren op verzoek 


Pagineren op verzoek kan een aanzienlijk effect hebben op het prestatievermogen 
van een computersysteem. Laten we, om te begrijpen waarom dat zo is, bij pa- 
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gineren op verzoek eens de effectieve toegangstijd tot het geheugen berekenen. De 
geheugentoegangstijd, gt, ligt voor de meeste computersystemen tussen de 500 
nanoseconden en de 2 microseconden. Zolang we geen paginafouten hebben, is 
de effectieve toegangstijd gelijk aan de geheugentoegangstijd. Als echter een pa- 
ginafout optreedt, moeten we eerst de betrokken pagina van het externe geheugen 
inlezen en dan de toegang tot het gewenste woord bewerkstelligen. 

Laat p de waarschijnlijkheid zijn dat een paginafout optreedt (0 < p < 1). 
We mogen aannemen dat p zeer dicht bij nul ligt, dat wil zeggen dat er slechts 
weinig paginafouten optreden. De effectieve toegangstijd, etg, is dan 


eig = (l-p) X gt + p X ’de duur van een paginafout’ 


Om de effectieve toegangstijd te kunnen berekenen moeten we weten hoe- 
veel tijd nodig is voor het behandelen van een paginafout. Een paginafout zet de 
volgende reeks van gebeurtenissen in werking: 


. Val’ gaat open naar het besturingssysteem. 
. Sla de registers en programmatoestand van de gebruiker op. 
. Stel vast dat de onderbreking een paginafout was. 
. Controleer of de paginaverwijzing legaal was en bepaal de plaats van de pa- 
gina op het externe geheugen. 
5. Doe een leesbewerking van het externe geheugen naar een vrij kader: 
a. Wacht in een wachtrij voor dit randapparaat tot de leesbewerking behan- 
deld wordt. 
b. Wacht tijdens de zoek- en wachttijd van het randapparaat. 
c. Begin met het overbrengen van de pagina naar het vrije kader. 
6. Terwijl we wachten kunnen we de CVE aan een andere gebruiker toewijzen 
(CVE-werkindeling). 
1. Onderbreking door het externe geheugen (I/O voltooid). 
8. Stel de registers en de programmatoestand voor de andere gebruiker veilig. 
9. Stel vast dat de onderbreking werd veroorzaakt door het externe geheugen. 
0. Werk de paginatabel en andere tabellen bij, om te laten zien dat de gewenste 
pagina nu in het geheugen is. 
11. Wacht tot de CVE weer aan dit proces wordt toegewezen. 
12. Zet de registers, programmatoestand en nieuwe paginatabel van de gebruiker 
in de oorspronkelijke toestand terug en hervat de uitvoering van de onder- 
broken instructie. 
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Deze stappen hoeven niet allemaal in ieder geval noodzakelijk te zijn. Bijvoor- 
beeld, in stap 5 namen we aan dat de CVE tijdens de I/O aan een ander proces 
wordt toegewezen. Deze regeling geeft multiprogrammering de mogelijkheid de 
CVE-gebruiksfactor op peil te houden, maar vereist extra tijd voor het overnemen 
van de besturing door de paginafout-routine wanneer de I/O-overbrenging klaar 
is. 
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In elk geval hebben we te maken met drie hoofdcomponenten van de tijd 
die nodig is voor het afhandelen van een paginafout: 


@ Het behandelen van de paginafout. 
@ Het in het geheugen brengen van de pagina. 
@ Het opnieuw starten van het proces. 


De eerste en derde taak kunnen met zorgvuldig coderen worden teruggebracht 
tot enkele honderden instructies. Deze taken kunnen ergens tussen de 100 en 
1000 microseconden duren. De tijd nodig voor het in het geheugen brengen van 
de pagina daarentegen zal waarschijnlijk dichtbij de 9 milliseconden (msec) lig- 
gen. Bijvoorbeeld, een trommel heeft gewoonlijk een wachttijd van 8 msec en een 
overbrengingstijd van 1 msec. Als een schijf met bewegende lees/schrijfkoppen 
als pagineerapparaat wordt gebruikt (een praktijk die nu meer in zwang raakt), 
moeten we zowel de zoektijd als de wachttijd en de overbrengingstijd in rekening 
brengen. Een randapparaat met bewegende lees/schrijfkoppen zou de totale tijd 
nodig voor het binnenbrengen van een pagina kunnen doen oplopen tot meer 
dan 30 msec. Denk er ook aan dat we alleen kijken naar de bedieningstijd van 
het randapparaat. Als er een rij van wachtende processen voor het randapparaat 
staat (andere processen die paginafouten hebben veroorzaakt), moeten we de tijd 
die in de wachtrij wordt doorgebracht tot het randapparaat vrijgekomen is om 
ons verzoek te behandelen, daar nog eens bij optellen. Dat verlengt de tijd voor 
het binnenbrengen van een pagina zelfs nog meer. 

Als we de gemiddelde tijd nodig voor het afhandelen van een paginafout 
op 10 msec stellen, en de geheugentoegangstijd op 1 microseconde (sec), dan 
vinden we voor de effectieve toegangstijd: 


(1-p) X (1 psec) + p X (10 msec) 
(1 — p) + 10000 x p psec 
1 + 9999 x p usec. 


etg 


We zien daaruit dat de effectieve toegangstijd recht evenredig is met de 
kans op een paginafout (p). Als op elke 1000 geheugentoegangen één paginafout 
optreedt, bedraagt de effectieve toegangstijd 11 microseconden. De computer zou 
door pagineren op verzoek met een factor 11 worden vertraagd. Willen we minder 
_ dan 10 procent vertraging, dan moet 


1,10 > 1 + 9999 x p 
0,10 > 9999 x p 
p < 0,00001 


Dat wil zeggen, om de vertraging als gevolg van pagineren op verzoek tot 
een redelijk niveau te beperken, kunnen we slechts 1 paginafout op de 100.000 
geheugentoegangen hebben. 


6.4 Paginavervanging 


Het is van groot belang de kans op paginafouten in een systeem met pagine- 
ren op verzoek laag te houden. Anders gaat de effectieve toegangstijd omhoog, 
waardoor de programma-uitvoering op dramatische wijze vertraagd wordt. 


6.4 Paginavervanging 


In ons betoog tot dusver is de kans op paginafouten niet echt een probleem, daar 
voor iedere pagina ten hoogste eenmaal een paginafout optreedt, te weten wan- 
neer daarnaar voor de eerste maal wordt verwezen. Deze voorstelling is strikt 
genomen niet juist. Als een programma van tien pagina’s nu eens de helft ervan 
gebruikt, dan kunnen we met pagineren op verzoek de I/O uitsparen die anders 
nodig is om de vijf pagina’s te laden die nooit worden gebruikt. We zouden ook 
ons multiprogrammeringsniveau kunnen verhogen door tweemaal zoveel pro- 
gramma's te draaien. Dus als we veertig kaders hadden, zouden we acht program- 
ma’s kunnen draaien in plaats van de vier die we zouden kunnen draaien als elk 
tien kaders vereiste (waarvan er vijf nooit worden gebruikt). 

Als we ons multiprogrammeringsniveau verder opvoeren, wijzen we teveel 
geheugen toe. Als we zes programma’s draaien, waarvan elk tien pagina’s groot 
is doch slechts vijf pagina’s werkelijk gebruikt, hebben we een hogere CVE-ge- 
bruiksfactor en doorvoercapaciteit, waarbij we nog tien kaders over hebben. Het 
is evenwel mogelijk dat elk van deze programma’s voor een speciale groep gege- 
vens plotseling probeert al zijn tien pagina’s te gebruiken. Dan zijn er zestig 
kaders nodig, terwijl er slechts veertig beschikbaar zijn. Nu mag deze situatie 
onwaarschijnlijk lijken, hij wordt veel waarschijnlijker als we het multiprogram- 
meringsniveau zodanig verhogen dat het gemiddelde geheugengebruik dichtbij 
het beschikbare fysieke geheugen komt. (Waarom zouden we in ons voorbeeld 
stoppen bij een multiprogrammeringsniveau van zes programma’s, wanneer we 
omhoog kunnen gaan naar een niveau van zeven of acht programma’s?) 

Het toewijzen van teveel geheugen zal zich op de volgende manier manifes- 
teren. Terwijl we bezig zijn een programma uit te voeren treedt er een paginafout 
op. Het programma loopt in de ‘val’ van de apparatuur naar het besturingssys- 
teem, dat zijn interne tabellen raadpleegt om te zien of dit een paginafout is en 
geen illegale geheugentoegang. Het besturingssysteem bepaalt waar de gewenste 
pagina zich op het externe geheugen bevindt, maar ontdekt dan dat er geen vrije 
kaders op de vrije-kaderlijst zijn; al het geheugen is in gebruik (zie figuur 6.5). 

Het besturingssysteem kan op dit moment verschillende dingen doen. Het 
zou het gebruikersprogramma kunnen beëindigen. Pagineren op verzoek is echter 
iets dat het besturingssysteem doet om de gebruiksfactor en de doorvoercapaciteit 
van het computersysteem te verbeteren. Gebruikers moeten niet eens in de gaten 
hebben dat hun programma’s op een systeem met paginering draaien. Paginering 
moet logisch doorzichtig zijn voor de gebruiker. Dus dit is niet de beste keuze. 

We zouden een programma uit het hoofdgeheugen kunnen zetten, om zo al 
zijn kaders vrij te maken en het multiprogrammeringsniveau naar beneden te 


Hoofdstuk6 Virtueel geheugen 


geldig / 
ongeldig-bit 


kader 
KarI 
ari 
5 $g 
BETI 


paginatabel 
logisch geheugen gebruiker 1 
gebruiker 1 


geldig/ 
ongeldig-bit 


kiai 
of A 
Del Pi ms 
geheugen 
IRE 
raed 


ict paginatabel 


logisch geheugen gebruiker 2 extern geheugen 
gebruiker 2 


Figuur 6.5 
De noodzaak tot paginavervanging 


brengen. Dit is soms een goed idee en we zullen het nader bekijken in paragraaf 
6.8.1, maar op dit moment is er een mogelijkheid die ons meer boeit: paginaver- 
vanging. 

Paginavervanging gaat uit van de volgende benadering. Als geen enkel 
kader vrij is, zoek er dan een op dat op het moment niet gebruikt wordt en maak 
het vrij. We kunnen een kader vrijmaken door de inhoud ervan naar het externe 
geheugen weg te schrijven en de paginatabel (en alle andere tabellen) te wijzigen 
om aan te geven dat de pagina niet langer in het geheugen is (zie figuur 6.6). Het 
vrijgemaakte kader kan nu worden gebruikt om de pagina op te nemen waarvoor 
de paginafout optrad. De paginafout-routine wordt nu zo gewijzigd dat pagina- 
vervanging daarbij inbegrepen is: 


1. Zoek de plaats op van de gewenste pagina op het externe geheugen. 
2. Zoek een vrij kader op. 
a. Als er een vrij kader is, gebruik dit. 
b. Gebruik anders een algoritme voor paginavervanging om een kaderslacht- 
offer te selecteren. | 
c. Schrijf het paginaslachtoffer naar het externe geheugen weg; wijzig de 
pagina- en kadertabellen dienovereenkomstig. 


6.4 Paginaverwijzing 


3. Lees de gewenste pagina in het (zojuist) vrijgemaakte kader in; wijzig de 
pagina- en kadertabellen. 
4, Start het gebruikersproces opnieuw. 


Merk op dat, als er geen kaders vrij zijn, twee pagina-overbrengingen (één uit en 
één in) vereist zijn. Deze situatie verdubbelt in feite de tijd die nodig is voor het 
afhandelen van een paginafout en zal de effectieve toegangstijd dienovereenkom- 
stig doen toenemen. 

Deze overhead kan worden verminderd door het gebruik van een mutatiebit. 
Elke pagina en elk kader kan een bijbehorende mutatiebit in de apparatuur heb- 
ben. De mutatiebit wordt door de apparatuur, telkens wanneer naar een woord 
of byte in de pagina geschreven wordt, gezet om aan te geven dat de pagina 
gewijzigd is. Bij het selecteren van een pagina voor vervanging inspecteren we 
zijn mutatiebit (elke pagina heeft zijn eigen mutatiebit). Als de bit aanstaat weten 
we dat de pagina gewijzigd is sinds deze van het externe geheugen is ingelezen. 
In dit geval moeten we de pagina naar het externe geheugen terugschrijven. Als 
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echter de mutatiebit niet aanstaat, is de pagina niet gewijzigd sinds deze in het 
geheugen ingelezen werd. Daarom kunnen we, als de kopie op het externe geheu- 
gen niet overschreven is (door een andere pagina bijvoorbeeld), het wegschrijven 
van de pagina naar het externe geheugen vermijden; de pagina is daar al. Deze 
methode kan de tijd nodig voor het behandelen van een paginafout aanzienlijk 
terugbrengen, omdat het de I/O-tijd met de helft bekort als de pagina niet ge- 
wijzigd is. 


6.5 Begrippen inzake virtueel geheugen 


Bij pagineren op verzoek is paginavervanging fundamenteel. Het maakt de schei- 
ding tussen logisch en fysiek geheugen compleet. Bij het niet op verzoek pagine- 
ren werden de gebruikersadressen vertaald in fysieke adressen, zodat de twee 
groepen adressen heel verschillend kunnen zijn. Bij pagineren op verzoek wordt 
de grootte van de logische adresruimte niet langer beperkt door het fysieke geheu- 
gen. Als we een gebruikersprogramma van twintig pagina’s hebben, kunnen we 
het in tien kaders uitvoeren, eenvoudig door gebruik te maken van pagineren op 
verzoek en een algoritme voor paginavervanging om een vrij kader te vinden 
wanneer dat maar nodig is. Als een pagina vervangen moet worden, wordt de 
inhoud naar het externe geheugen gekopieerd. Een verwijzing naar de pagina op 
een later tijdstip zal een paginafout veroorzaken. Op dat moment zal de pagina 
in het geheugen worden teruggebracht, waarbij hij misschien een andere pagina 
in het proces vervangt. 

Virtueel geheugen is de scheiding van het logische geheugen van de gebrui- 
ker en het fysieke geheugen, en is gewoonlijk geïmplementeerd in de vorm van 
pagineren op verzoek. Op deze wijze kan aan programmeurs een zeer groot vir- 
tueel geheugen op een kleiner fysiek geheugen ter beschikking worden gesteld 
(zie figuur 6.7). Virtueel geheugen maakt de taak van het programmeren veel 
gemakkelijker, daar de programmeur zich niet langer hoeft te bekommeren om 
de beschikbare hoeveelheid fysiek geheugen, maar zich kan concentreren op het 
probleem dat moet worden geprogrammeerd. Een resultaat van virtueel geheugen 
is geweest dat het gebruik van overlappende programmasegmenten praktisch ver- 
dwenen is. 

Virtueel geheugen kan ook met behulp van een segmenteringssysteem wor- 
den geïmplementeerd. Verscheidene systemen, zoals Multics, hebben een seg- 
menteringssysteem met paginering, waarin segmenten zijn verdeeld in pagina's. 
Zo is wat de gebruiker ziet segmentering, maar het besturingssysteem kan dit 
gezichtspunt implementeren met behulp van pagineren op verzoek. Segmenteren 
op verzoek kan ook worden gebruikt om virtueel geheugen te leveren. Computer- 
systemen van Burroughs hebben gebruik gemaakt van segmenteren op verzoek. 
Algoritmen voor segmentvervanging zijn echter complexer dan algoritmen voor 
paginavervanging wegens de van nature variabele grootte van segmenten. 

Twee belangrijke problemen moeten worden opgelost om pagineren op ver- 
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Figuur 6.7 
Het virtuele geheugen kan veel groter zijn dan het fysieke geheugen 


zoek te implementeren: het algoritme voor kadertoewijzing en het algoritme voor 
paginavervanging. Als we meerdere processen in het geheugen hebben, moeten we 
beslissen hoeveel kaders aan elk proces moeten worden toegewezen. Verder moe- 
ten we, wanneer paginavervanging nodig is, de kaders selecteren die vervangen 
moeten worden. \ 


6.6 Algoritmen voor paginavervanging 


Er is een groot aantal verschillende algoritmen voor paginavervanging. Waar- 
schijnlijk heeft elk besturingssysteem zijn eigen unieke vervangingsmethode. Hoe 
zoeken we uit alle algoritmen voor paginavervanging er één uit? In het algemeen 
willen we het algoritme hebben met de kleinste kans op paginafouten. 

De waarde van een algoritme wordt bepaald door het los te laten op een 
bepaalde reeks geheugenverwijzingen en dan het aantal paginafouten te bereke- 
nen. De reeks geheugenverwijzingen heet een verwijzingsreeks. Verwijzingsreek- 
sen kunnen kunstmatig worden gegenereerd (bijvoorbeeld door een generator van 
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toevalsgetallen), of door van een gegeven systeem een detailverslag (‘trace’) te 
maken en het adres van elke geheugenverwijzing vast te leggen. De tweede keuze 
produceert een zeer grote hoeveelheid gegevens (in de orde van grootte van een 
miljoen adressen per seconde). Met het oog op het reduceren van de hoeveelheid 
gegevens merken we twee dingen op. 

Ten eerste hoeven we voor een gegeven paginagrootte (en de paginagrootte 
ligt in het algemeen vast door de apparatuur of het systeem) alleen het pagina- 
nummer te beschouwen, niet het gehele adres. Ten tweede zullen, als we een 
verwijzing naar pagina p hebben, alle onmiddellijk daarop volgende verwijzingen 
naar pagina p nooit een paginafout veroorzaken. Pagina p is na de eerste verwij- 
zing in het geheugen; de onmiddellijk daarop volgende verwijzingen zullen geen 
paginafout opleveren. 

Bijvoorbeeld, als we van een bepaald programma een detailverslag maken, 
zouden we de volgende reeks adressen kunnen vastleggen: 


0100, 0432, 0101, 0612, 0102, 0103, 0104, 0101, 0611, 0102, 0103, 
0104, 0101, 0610, 0102, 0103, 0104, 0101, 0609, 0102, 0105 


die, bij honderd woorden per pagina, wordt teruggebracht tot de volgende verwij- 
zingsreeks: 


1, 40, 6, LGLI Ol. 


Om het aantal paginafouten voor een bepaalde verwijzingsreeks en een be- 
paald algoritme voor paginavervanging vast te stellen, moeten we ook het aantal 
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Figuur 6.8 j 
Grafiek van het aantal paginafouten als functie van het aantal kaders 
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beschikbare kaders weten. Het is duidelijk dat, wanneer het aantal beschikbare 
kaders toeneemt, het aantal paginafouten zal afnemen. Voor bijvoorbeeld de bo- 
venvermelde verwijzingsreeks zouden we, als we drie of meer kaders beschikbaar 
hadden, slechts drie paginafouten hebben: één paginafout voor de eerste verwij- 
zing naar iedere pagina. Aan de andere kant zouden we, bij slechts één beschik- 
baar kader, een vervanging hebben bij elke verwijzing, met als resultaat elf pa- 
ginafouten. In het algemeen verwachten we een kromme zoals die van figuur 6.8. 
Naarmate het aantal kaders toeneemt, loopt het aantal paginafouten terug tot 
een minimumniveau. 

Laten we ter illustratie van de volgende algoritmen voor paginavervanging 
de onderstaande verwijzingsreeks gebruiken: 


ONK oy 0, 4, 2, 3, 0; 3; 2, 1,2, 0; 1, 7, 0,1 


voor een geheugen met drie kaders. 


6.6.1 FIFO 


Het eenvoudigste algoritme voor paginavervanging is Eerst-In-Eerst-Uit (First- 
In-First-Out, FIFO). Een FIFO-vervangingsalgoritme houdt voor iedere pagina 
het tijdstip bij waarop deze in het geheugen werd gebracht. Wanneer een pagina 
vervangen moet worden, wordt de oudste pagina gekozen. Merk op dat het niet 
strikt noodzakelijk is om het tijdstip waarop een pagina werd binnengebracht te 
bewaren. We kunnen een FIFO-wachtrij opzetten voor alle pagina’s die in het 
geheugen gehouden worden. We vervangen de pagina vooraan in de wachtrij. 
Wanneer een pagina in het geheugen wordt gebracht, zetten we deze achteraan 
in de wachtrij. 

Voor onze voorbeeld-verwijzingsreeks zijn onze drie kaders aanvankelijk 
leeg. De eerste drie verwijzingen (7, 0, 1) veroorzaken paginafouten, waarop de 
pagina’s in het geheugen worden gebracht. De volgende verwijzing (2) vervangt 
pagina 7, omdat pagina 7 het eerst in het geheugen gebracht werd. Aangezien 0 
de volgende verwijzing is en 0 al in het geheugen is, hebben we geen paginafout 
als gevolg van deze verwijzing. De eerste verwijzing naar pagina 3 heeft als gevolg 
dat pagina 0 wordt vervangen, omdat deze als eerste van de drie pagina’s in het 
geheugen (0, 1 en 2) naar binnen werd gebracht. Deze vervanging betekent dat 
de volgende verwijzing, naar pagina 0, een paginafout oplevert. Pagina 1 wordt 
dan vervangen door pagina 0. Dit proces gaat door zoals is aangegeven in figuur 
6.9. Elke keer dat een paginafout optreedt laten we zien welke pagina’s zich in 
onze drie kaders bevinden. Er zijn bij elkaar vijftien paginafouten. 

Het FIFO-algoritme voor paginavervanging is gemakkelijk te begrijpen en 
te programmeren. Het prestatievermogen is echter niet altijd zo goed. De vervan- 
gen pagina kan een initialiseringsmodule zijn die lang geleden gebruikt werd en 
niet langer nodig is. Aan de andere kant zou de pagina een veel gebruikte varia- 
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Figuur 6.9 
FIFO-paginavervanging 


bele kunnen bevatten die vroegtijdig geïnitialiseerd werd en voortdurend in ge- 
bruik is. 

Let erop dat alles nog steeds correct werkt, zelfs als we ter vervanging een 
pagina selecteren die actief gebruikt wordt. Na het uit het geheugen zetten van 
een actieve pagina om een nieuwe binnen te brengen, hebben we bijna onmiddel- 
lijk een paginafout voor de actieve pagina. 

Er zal een andere pagina vervangen moeten worden om de actieve pagina 
weer in het geheugen terug te brengen. Zo verhoogt een slechte vervangingskeuze 
de kans op een paginafout en vertraagt dit de programma-uitvoering, maar dit 
veroorzaakt geen incorrecte uitvoering. 

Kijk, ter illustratie van de problemen met een FIFO-algoritme voor pagina- 
vervanging, eens naar de verwijzingsreeks: 


1233, 4; 14:45, i 94, 5 


Figuur 6.10 laat de paginafoutenkromme zien als functie van het aantal beschik- 
bare kaders. We zien dat het aantal paginafouten voor vier kaders (10) groter is 
dan het aantal paginafouten voor drie kaders (9)! Dit resultaat is heel onverwacht 
en staat bekend als de anomalie van Belady. De anomalie van Belady weerspiegelt 
het feit dat voor sommige algoritmen voor paginavervanging de kans op pagina- 
fouten kan toenemen wanneer het aantal toegewezen kaders toeneemt. Men zou 
verwachten dat door meer geheugen aan een programma te geven het prestatie- 
vermogen ervan zou verbeteren. In een onderzoek uit vroeger jaren bleek dat 
deze veronderstelling niet altijd opging. Het resultaat was de ontdekking van de 
anomalie van Belady. 


6.6.2 Optimale vervanging 


Een gevolg van de ontdekking van de anomalie van Belady was dat men ging 
zoeken naar een optimaal algoritme voor paginavervanging. Een optimaal algorit- 
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Figuur 6.10 
Paginafoutencurve voor FIFO-vervanging aan de hand van een reeks paginaverwijzingen 


me voor paginavervanging heeft van alle algoritmen de kleinste kans op een pa- 
ginafout. Een optimaal algoritme zou nooit mank gaan aan de anomalie van 
Belady. Er bestaat een optimaal algoritme voor paginavervanging. Het wordt 
OPT of MIN genoemd. Het stelt simpel: 


Vervang die pagina die het langst 
niet zal worden gebruikt. 


Het gebruik van dit algoritme garandeert de kleinst mogelijke kans op een 
paginafout voor een vast aantal kaders. 

Op bijvoorbeeld onze voorbeeld-verwijzingsreeks zou het optimale algoritme 
voor paginavervanging negen paginafouten geven, zoals aangegeven is in figuur 
6.11. De eerste drie verwijzingen veroorzaken paginafouten, die de drie lege ka- 
ders vullen. De verwijzing naar pagina 2 vervangt pagina 7, omdat 7 niet gebruikt 
zal worden tot verwijzing 18, terwijl pagina 0 gebruikt zal worden bij verwijzing 
5, en pagina 1 bij 14. De verwijzing naar pagina 3 vervangt pagina 1, omdat van 
de pagina’s in het geheugen pagina 1 de laatste is waarnaar weer zal worden 
verwezen. Met slechts negen paginafouten is optimale vervanging veel beter dan 
FIFO, dat vijftien paginafouten had. (Als we de eerste drie paginafouten, die alle 
algoritmen moeten ondergaan, verwaarlozen, dan is optimaal tweemaal zo goed 
als FIFO.) In feite kan geen enkel algoritme deze verwijzingsreeks in drie kaders 
met minder dan negen paginafouten verwerken. 
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Figuur 6.11 
Optimale paginavervanging 


Helaas is het optimale algoritme voor paginavervanging moeilijk te imple- 
menteren, daar dit kennis vooraf van de verwijzingsreeks vereist. (Een soortgelij- 
ke situatie zijn we tegengekomen bij het Kortste-Job-Eerst-algoritme voor CVE- _ 
werkindeling in paragraaf 4.3.3.) Bijgevolg wordt het optimale algoritme hoofd- 
zakelijk gebruikt voor vergelijkende studies. Het kan erg nuttig zijn te weten dat, 
hoewel een nieuw algoritme niet optimaal is, het in het slechtste geval binnen 
12,3%, en gemiddeld 4,7%, van optimaal af ligt. 


6.6.3 Minst-Recent-Gebruikt 


Al is het optimale algoritme niet praktisch te verwezenlijken, misschien is dan 
toch een benadering van het optimale algoritme mogelijk. Het hoofdonderscheid 
tussen FIFO en OPT (afgezien van het achteruit of vooruit kijken in de tijd) is 
dat FIFO het tijdstip gebruikt waarop een pagina in het geheugen werd gebracht, 
terwijl OPT het tijdstip gebruikt waarop een pagina gebruikt gaat worden. Als 
we het recente verleden als een benadering van de naaste toekomst gebruiken, 
zouden we die pagina willen vervangen die het langst niet gebruikt is (zie figuur 
6.12). Dit is het Minst-Recent-Gebruikt-algoritme (MRG). 

MRG-vervanging verbindt met elke pagina het tijdstip waarop deze het 
laatst werd gebruikt. Wanneer een pagina vervangen moet worden, kiest MRG 
die pagina die het langst niet gebruikt is. Dit is het optimale algoritme voor 
paginavervanging bij achteruit kijken in de tijd in plaats van vooruit. (Trouwens, 
een veel gebruikte techniek voor het genereren van het aantal paginafouten voor 
OPT voor een bepaalde verwijzingsreeks is het omkeren van de hele reeks en het 
gebruiken van MRG voor deze in-de-tijd omgekeerde verwijzingsreeks.) 

Het gevolg van het toepassen van MRG op onze voorbeeld-verwijzingsreeks 
ziet u in figuur 6.12. MRG produceert twaalf paginafouten. U ziet dat de eerste 
vijf paginafouten dezelfde zijn als bij optimale vervanging. Wanneer evenwel de 
verwijzing naar pagina 4 plaatsvindt, ziet MRG dat van de drie geheugenkaders 
pagina 2 het minst recent gebruikt werd. De meest recent gebruikte pagina is 
pagina 0, terwijl meteen daarvoor pagina 3 werd gebruikt. Aldus vervangt MRG 
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Figuur 6.12 
‘Minst-Recent-Gebruikt (MRG)’ paginavervanging 


pagina 2, niet wetend dat die op het punt staat gebruikt te worden. Wanneer dan 
de fout optreedt voor pagina 2, vervangt MRG pagina 3, omdat van de drie 
pagina’s in het geheugen 0, 3, 4, pagina 3 de minst recent gebruikte is. Ondanks 
deze problemen is MRG met twaalf paginafouten nog steeds veel beter dan FIFO 
met vijftien. 

MRG wordt vaak als algoritme voor paginavervanging gebruikt en wordt 
als heel goed beschouwd. Het grote probleem is hoe MRG geimplementeerd moet 
worden. 

Een MRG-algoritme voor paginavervanging kan aanzienlijke assistentie 
van de apparatuur vereisen. Het probleem is hoe voor de kaders een volgorde 
bepaald kan worden op grond van het tijdstip waarop deze voor het laatst werden 
gebruikt. Er zijn twee implementaties mogelijk. 


@ Tellers. In het simpelste geval verbinden we met iedere paginatabel-ingang een 
tijd-van-gebruik-register en voegen we aan de CVE een logische klok of teller 
toe. De klok wordt bij iedere geheugenverwijzing opgehoogd. Telkens wanneer 
een verwijzing naar een pagina wordt gemaakt, wordt de inhoud van het klok- 
register naar het tijd-van-gebruik-register van de paginatabel-ingang voor die 
pagina gekopieerd. Op deze manier hebben we altijd het ’tijdstip’ van de laat- 
ste verwijzing naar iedere pagina. We vervangen dan de pagina met de kleinste 
tijdswaarde. Dit schema vereist een doorzoeken van de paginatabel om de 
minst recent gebruikte pagina te vinden. De tijden moeten ook worden bijge- 
houden wanneer de paginatabellen worden verwisseld (wegens CVE-werkinde- 
ling). Overloop van de klok moet in de gaten gehouden worden. 

@ Stapel. Een andere benaderingswijze van de implementatie van MRG is het 
bijhouden van een stapel van paginanummers. Telkens wannneer naar een pa- 
gina wordt verwezen, wordt deze uit de stapel gehaald en bovenaan geplaatst. 
Op deze manier is de top van de stapel altijd de meest recent gebruikte pagina 
en is de onderkant de minst recent gebruikte pagina (zie figuur 6.13). Aange- 
zien ingangen uit het midden van de stapel moeten worden gehaald, kan deze 
het best worden geïmplementeerd met behulp van een dubbel-aaneenge- 
schakelde lijst, met een kop- en een staartwijzer. Het verwijderen van een pa- 
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Figuur 6.13 
Gebruik van een stapel voor het vastleggen van de meest recente paginaverwijzingen 


gina om deze bovenaan de stapel te zetten vereist in het ongunstigste geval het 
wijzigen van zes wijzers. Elke wijziging wordt daardoor wat duurder, maar er 
hoeft niet naar vervanging gezocht te worden; de staartwijzer wijst naar de 
onderkant van de stapel, de minst recent gebruikte pagina. Deze benadering 
is vooral geschikt voor implementaties van MRG in de programmatuur of de 
microcode. 


Noch optimale vervanging noch MRG-vervanging gaan mank aan de 
anomalie van Belady. Er is een groep algoritmen voor paginavervanging die 
stapel-algoritmen worden genoemd en die nooit de anomalie van Belady te zien 
geven. Een stapel-algoritme is een algoritme waarvoor kan worden aangetoond 
dat de groep pagina’s in het geheugen bij n kaders altijd een deelverzameling is 
van de groep pagina’s in het geheugen bij n+1 kaders. Voor MRG bestaat de 
groep pagina’s in het geheugen uit de n meest recent gebruikte pagina’s. Als het 
aantal kaders wordt vermeerderd, zullen deze n pagina’s nog steeds de meest 
recent gebruikte zijn en dus nog steeds in het geheugen zijn. 

Let erop dat er geen implementatie van MRG denkbaar is zonder assisten- 
tie van de apparatuur. Het bijwerken van de klokregisters of de stapel moet voor 
elke geheugenverwijzing gebeuren. Als we een onderbreking voor elke verwijzing 
zouden willen gebruiken, om de programmatuur gelegenheid te geven zulke ge- 
gevensstructuren bij te werken, zou elke geheugenverwijzing met een factor van 
ten minste 10 worden vertraagd, en zou dientengevolge elk gebruikersprogramma 
met een factor 10 worden vertraagd. Maar weinig systemen zouden zich een der- 
gelijke overhead voor geheugenbeheer kunnen permitteren. 
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6.6.4 Benadering van MRG 


Weinig systemen bieden voldoende ondersteuning door de apparatuur voor echte 
MRG-paginavervanging. Sommige systemen geven geen ondersteuning door de 
apparatuur en dan moeten andere algoritmen voor paginavervanging (zoals 
FIFO) worden gebruikt. Veel systemen bieden echter toch enige hulp, in de vorm 
van een referentiebit. De referentiebit voor een pagina wordt door de apparatuur 
gezet wanneer naar die pagina wordt verwezen (door een lees- of een schrijf- 
bewerking van of naar een woord of byte in de pagina). Referentiebits worden 
met elke ingang in de paginatabel verbonden of vormen een apart register met 
één bit voor elk kader. Speciale instructies zorgen voor het aflezen en op nul 
zetten van deze bits. 

Aanvankelijk worden alle bits door het besturingssysteem afgezet. Als een 
gebruikersprogramma aan zijn uitvoering bezig is, wordt de bit behorende bij 
elke pagina waarnaar verwezen wordt, door de apparatuur aangezet. Na enige 
tijd kunnen we, door de referentiebits te inspecteren, bepalen welke pagina’s wel 
en welke niet gebruikt zijn. We kennen niet de volgorde waarin ze gebruikt wer- 
den, maar we weten welke pagina’s wel en welke niet gebruikt werden. Deze 
gedeeltelijke informatie betreffende de volgorde leidt tot veel algoritmen voor 
paginavervanging die trachten de MRG-vervanging te benaderen. 


Extra referentiebits | 
Men kan extra informatie aangaande de volgorde verkrijgen door de referentie- 
bits met regelmatige tussenpozen af te lezen. We kunnen voor elke pagina-ingang 
een byte (8 bits) in een tabel in het geheugen bijhouden. Met regelmatige tussen- 
pozen (zeg elke 100 msec) geeft een onderbreking door een tijdregister de bestu- 
ring aan het besturingssysteem. Het besturingssysteem schuift de referentiebit 
voor elke pagina in de meest significante bit van de byte van 8 bits, nadat eerst 
de andere bits één bit naar rechts zijn geschoven en de minst sigificante bit is 
weggevallen. Deze schuifregisters van 8 bits bevatten de geschiedenis van het 
paginagebruik gedurende de laatste acht intervallen. Als het schuifregister 
00000000 bevat, dan is de pagina gedurende acht intervallen niet gebruikt; een 
_ pagina die ten minste één maal per tijdsinterval gebruikt werd zou een schuifre- 
gisterwaarde 11111111 hebben. 

Een pagina waarvan het geschiedenisregister de waarde 11000100 aangeeft 
is recenter gebruikt dan één met de waarde 01110111. Als we deze bytes van 8 
bits opvatten als gehele getallen zonder teken, is de pagina met het laagste getal 
de minst recent gebruikte, en kan deze dus vervangen worden. Let er echter op 
dat het niet zeker is dat de getallen uniek zijn. We kunnen óf alle pagina’s met 
de laagste getalwaarde vervangen (uit het geheugen zetten) óf een FIFO-selectie 
op ze toepassen. 

Het aantal geschiedenisbits kan men natuurlijk variëren en het moet zo 
gekozen worden dat het bijwerken zo snel mogelijk gaat. In het uiterste geval kan 
dit aantal tot nul worden gereduceerd, zodat alleen de referentiebit zelf overblijft. 
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Dit algoritme wordt het ’tweede-kans’-algoritme voor paginavervanging ge- 
noemd. 


Tweede-kans-vervanging 

Het basisalgoritme voor tweede-kans-vervanging is een FIFO-vervangingsal- 
goritme. Echter, wanneer een pagina wordt geselecteerd, inspecteren we zijn re- 
ferentiebit. Als dit 0 is, vervangen we deze pagina inderdaad. Als de referentiebit 
echter gezet is, geven we de pagina een tweede kans en selecteren we met FIFO 
de volgende pagina. 

Wanneer een pagina een tweede kans krijgt, wordt zijn referentiebit afgezet 
en wordt zijn aankomsttijd gelijkgezet aan de huidige tijd. Dus een pagina die 
een tweede kans krijgt wordt niet vervangen totdat alle andere pagina’s zijn ver- 
vangen (of een tweede kans hebben gekregen). Bovendien zal een pagina die zo 
vaak gebruikt wordt dat zijn referentiebit altijd aanstaat nooit worden vervangen. 

Eén manier om het tweede-kans-algoritme te beschouwen is als een rond- 
lopende wachtrij. Een wijzer geeft aan welke pagina aan de beurt is om te worden 
vervangen. Wanneer een kader nodig is, gaat de wijzer verder tot hij een pagina 
vindt waarvan de referentiebit afstaat. Bij het verder gaan zet hij de referentiebits 
af (zie figuur 6.14). In het ongunstigste geval, wanneer alle bits aanstaan, cir- 
culeert de wijzer door de gehele wachtrij, waarbij elke pagina een tweede kans 
krijgt. Alle refentiebits worden afgezet voordat de volgende pagina voor vervan- 
ging geselecteerd wordt. Tweede-kans degenereert tot FIFO als alle bits aanstaan. 


Minst Frequent Gebruikt 

Minst Frequent Gebruikt (MiFG) houdt een teller bij van alle verwijzingen die 
naar elke pagina zijn gemaakt. De pagina met de kleinste waarde in de teller 
wordt vervangen. De beweegreden voor deze selectie is dat een actief gebruikte 
pagina een groot aantal verwijzingen zal hebben. Dit algoritme werkt niet goed 
in de situatie dat een pagina zeer intensief gebruikt werd tijdens de initialiserings- 
fase van een programma, terwijl hij daarna nooit meer gebruikt wordt. Omdat 
de pagina intensief gebruikt werd, heeft hij een groot aantal verwijzingen en blijft 
hij in het geheugen hoewel hij niet meer nodig is. Een oplossing is dat we met 
regelmatige tussenpozen de telling één bit naar rechts verschuiven, waardoor de 
telling exponentieel afneemt. 


Meest Frequent Gebruikt 

Een ander algoritme voor paginavervanging is Meest Frequent Gebruikt (MeFG), 
dat ervan uitgaat dat de pagina met het kleinste aantal verwijzingen waarschijn- 
lijk net naar binnen gehaald werd en nog gebruikt moet worden. Zoals u mis- 
schien wel verwachtte, zijn noch MeFG noch MiFG erg gebruikelijk. De imple- 
mentatie van deze algoritmen is tamelijk kostbaar. 


Paginaklassen 
Er zijn vele andere algoritmen die gebruikt worden voor paginavervanging. Als 
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Figuur 6.14 
"Tweede-kans’ paginavervanging 


we bijvoorbeeld de referentie- en de mutatiebit (paragraaf 6.4) als een geordend 
paar beschouwen, hebben we de volgende vier klassen: 


0. (0,0) noch gebruikt noch gewijzigd. 

1. (0,1) niet (recent) gebruikt maar wel gewijzigd. 
2. (1,0) wel gebruikt maar ongewijzigd. 

3. (1,1) wel gebruikt en ook gewijzigd. 


Wanneer paginavervanging nodig is, behoort elke pagina tot één van deze vier 
klassen. We vervangen de pagina in de laagste niet-lege klasse. Zijn er meerdere 
pagina’s in de laagste klasse, dan kunnen we FIFO gebruiken of willekeurig uit 
deze pagina’s kiezen. 


6.6.5 Ad hoc algoritmen 


Naast een specifiek algoritme voor paginavervanging worden vaak ook nog ande- 
re procedures gebruikt. Systemen houden bijvoorbeeld gewoonlijk een pot van 
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vrije kaders bij. Treedt een paginafout op, dan wordt net zoals we eerst zagen een 
kaderslachtoffer gekozen. De gewenste pagina wordt evenwel in een vrij kader uit 
de pot ingelezen voordat het slachtoffer wordt weggeschreven. Deze procedure 
stelt het programma in staat zijn werking zo spoedig mogelijk te hervatten, zon- 
der dat het moet wachten op het wegschrijven van het paginaslachtoffer. Wan- 
neer het slachtoffer later is weggeschreven, wordt zijn kader aan de vrije-kaderpot 
toegevoegd. | 

In een uitbreiding van dit idee wordt een lijst van gewijzigde pagina’s bijge- 
houden. Telkens wanneer het pagineerapparaat zonder werk is, wordt een ge- 
wijzigde pagina geselecteerd en naar het externe geheugen weggeschreven. De 
mutatiebit wordt dan weer afgezet. Deze opzet verhoogt de kans dat een pagina 
ongewijzigd is wanneer deze voor vervanging wordt geselecteerd en dus niet weg- 
geschreven hoeft te worden. 

Een andere wijziging is het bijhouden van een vrije-kaderpot, waarbij we 
ons dan tevens herinneren welke pagina zich in elk kader bevond. Aangezien de 
kaderinhoud niet gewijzigd wordt wanneer het kader naar het externe geheugen 
wordt weggeschreven, kan de oude pagina uit de vrije-kaderpot direct wanneer 
dat nodig is weer worden gebruikt voordat het kader opnieuw gebruikt wordt. In 
dit geval komt er geen I/O aan te pas. Wanneer er een paginafout optreedt, 
controleren we eerst of de gewenste pagina zich in de vrije-kaderpot bevindt. Zo 
niet, dan moeten we een vrij kader selecteren en de pagina daarin inlezen. 

Deze techniek wordt in het VAX/VMS systeem gebruikt, samen met een 
FIFO-vervangingsalgoritme. Wanneer het FIFO-vervangingsalgoritme per abuis 
een pagina vervangt die nog actief gebruikt wordt, wordt deze snel weer opge- 
spoord in de vrije-kaderbuffer en is er geen I/O nodig. De vrije-kaderbuffer biedt 
bescherming tegen het betrekkelijk slechte, maar simpele, FIFO-vervangingsal- 
goritme. 


6.7 Algoritmen voor paginatoewijzing 


Wanneer we eenmaal een vervangingsalgoritme hebben uitgezocht, hebben we 
een aanzienlijke flexibiliteit in ons geheugenbeheer. Het virtuele geheugen van 
de gebruiker kan veel groter zijn dan het fysieke geheugen. Pagineren op verzoek 
en paginavervanging geven ons de mogelijkheid om zelfs in een klein fysiek ge- 
heugen grote programma’s uit te voeren. 

Het eenvoudigste geval van virtueel geheugen is het systeem met één gebrui- 
ker. Neem een microcomputersysteem voor één enkele gebruiker met een geheu- 
gen van 128K bytes dat uit pagina’s van 1K bestaat. Het besturingssysteem zal 
misschien 35K bytes in beslag nemen, zodat 93 kaders voor het gebruikerspro- 
gramma overblijven. Met zuiver pagineren op verzoek zouden al de 93 kaders in 
het begin op de vrije-kaderlijst worden gezet. Bij het begin van de uitvoering van 
een gebruikersprogramma zou een reeks paginafouten worden gegenereerd. De 
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eerste 93 paginafouten zouden alle een vrij kader krijgen van de vrije-kaderlijst. 
Wanneer de vrije-kaderlijst leeg is zou een algoritme voor paginavervanging wor- 
den gebruikt om één van de 93 pagina’s in het geheugen te selecteren om deze te 
vervangen door de 94ste, enzovoort. Bij beëindiging van het programma zouden 
de 93 kaders weer op de vrije-kaderlijst worden geplaatst. 

Op deze eenvoudige strategie bestaan vele variaties. We kunnen eisen dat 
het besturingssysteem al zijn buffer- en tabelruimte uit de vrije-kaderlijst toe- 
wijst. Is deze ruimte niet in gebruik door het besturingssysteem, dan kan deze 
worden gebruikt om paginering voor de gebruiker te ondersteunen. We zouden 
kunnen proberen deze vrije kaders voortdurend op de vrije-kaderlijst in reserve 
te houden. Dan is er dus, wanneer een paginafout optreedt, een vrij kader be- 
schikbaar om daarin de pagina in te lezen. Terwijl de paginaverwisseling plaats- 
vindt, kan een pagina ter vervanging worden geselecteerd; deze wordt dan weg- 
geschreven naar het externe geheugen wanneer het gebruikersprogramma met 
zijn uitvoering verder gaat. 

Er zijn ook andere varianten mogelijk, maar de basisstrategie is duidelijk: 
elk vrij kader wordt aan het gebruikersprogramma toegewezen. 

Een ander probleem doet zich voor wanneer pagineren op verzoek wordt 
gecombineerd met multiprogrammering. Multiprogrammering zet twee (of meer) 
programma's gelijktijdig in het geheugen. Hoe wijzen we de vaste hoeveelheid 
kaders toe aan de diverse processen? Als we 93 vrije kaders en 2 processen heb- 
ben, hoeveel kaders krijgt elk proces dan? 


6.7.1 Minimumaantal kaders 


Voor onze toewijzing gelden natuurlijk beperkingen. We kunnen niet meer dan 
het totale aantal beschikbare kaders toewijzen (tenzij er sprake is van gemeen- 
schappelijk gebruik van een pagina). Er is ook een minimumaantal kaders dat 
kan worden toegewezen. Het is duidelijk dat de kans op een paginafout (en daar- 
mee de effectieve toegangstijd) omhoog gaat naarmate het aantal kaders dat aan 
elk proces is toegewezen afneemt, waardoor de uitvoering van het proces wordt 
vertraagd. 

Afgezien van de ongewenste prestatie-eigenschappen van het toewijzen van 
slechts een paar kaders, is er een minimumaantal kaders dat moet worden toe- 
gewezen. Dit minimumaantal wordt gedefinieerd door de architectuur van de 
instructieset. Denk eraan dat wanneer er een paginafout optreedt voordat de 
uitvoering van een instructie voltooid is, de instructie opnieuw moet worden ge- 
start. Daarom moeten we genoeg kaders hebben om alle verschillende pagina’s 
te kunnen bevatten waarnaar elke instructie afzonderlijk kan verwijzen. 

Neem bijvoorbeeld de PDP-8. Al zijn instructies met geheugenverwijzing 
hebben slechts één geheugenadres. Daarom hebben we ten minste één kader no- 
dig voor de instructie en één voor de geheugenverwijzing. Bovendien kan het 
adres dat in de instructie is gespecificeerd een indirecte verwijzing zijn. Dus een 
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laad-instructie in pagina 16 kan naar een adres in pagina 0 verwijzen dat zelf 
weer een indirecte verwijzing naar pagina 23 is. Daarom vereist paginering op de 
PDP-8 minstens drie kaders per proces. Denk eens aan wat er zou kunnen gebeu- 
ren als een proces slechts twee kaders had. 

Het minimumaantal kaders wordt gedefinieerd door de computerarchitec- 
tuur. Waar de PDP-8 drie kaders vereist, vereist de PDP-11 er ten minste zes. 
De overbreng-instructie (move) is voor sommige adresseer-modi al meer dan één 
woord en dus kan de instructie over de grens van twee pagina’s heen liggen. 
Bovendien kan elk van zijn twee operanden uit indirecte verwijzingen bestaan, 
zodat het totaal op zes kaders komt. Het ongunstigste geval voor de IBM 370 is 
waarschijnlijk de tekenoverbreng-instructie (move character). Aangezien de in- 
structie van geheugen naar geheugen overbrengt, is deze zes bytes lang en kan 
deze in twee pagina’s liggen. Het blok tekens dat moet worden overgebracht en 
het gebied waarnaar de overbrenging plaatsvindt kunnen elk ook in twee pagina's 
liggen. Deze situatie zou zes kaders vereisen. (Eigenlijk is het ongunstigste geval 
als de tekenoverbreng-instructie de operand is van een uitvoerings-instructie 
(execute) die over een paginagrens heen ligt; in dit geval hebben we acht kaders 
nodig.) 

De architectuur van de Nova 3 van Data General had de mogelijkheid van 
meerdere niveaus van indirecte adressering: elk woord van zestien bits kon een 
adres van vijftien bits bevatten plus een direct/indirect-bit. Theoretisch zou een 
eenvoudige laad-instructie kunnen verwijzen naar een indirect adres, dat zou 
kunnen verwijzen naar een indirect adres (in een andere pagina), dat ook weer 
zou kunnen verwijzen naar een indirect adres (in weer een andere pagina), enzo- 
voort, tot elke pagina in het virtuele geheugen hierbij betrokken zou zijn. Dus in 
het ongunstigste geval moet het gehele virtuele geheugen in het fysieke geheugen 
zijn. Toen ze zich realiseerden dat geen echt programma ooit veel gebruik van 
deze ’voorziening’ zou maken, wijzigden de technici de architectuur toen pagine- 
ring werd toegevoegd zodanig dat een instructie werd beperkt tot zestien niveaus 
van indirecte adressering. Bij de eerste indirecte adressering wordt een teller op 
16 gezet en bij elke volgende indirecte adressering voor deze instructie wordt de 
teller verlaagd. Als de teller op nul komt gaat een ’val’ open (overschrijding indi- 
recte adressering). Deze beperking brengt het maximumaantal geheugenver- 
wijzingen, en daarmee het maximumaantal kaders, terug tot 17. 

Het minimumaantal kaders per proces wordt gedefinieerd door de architec- 
tuur, terwijl het maximumaantal wordt gedefinieerd door de hoeveelheid beschik- 
baar geheugen. Daartussen hebben we nog ruimschoots keus voor de toewijzing 
van kaders. 


6.7.2 Globale versus lokale toewijzing 


Wij hoeven niet expliciet te beslissen hoeveel kaders aan elk proces moeten wor- 
den toegewezen. Als meerdere processen om kaders wedijveren, kunnen we twee 
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brede categorieën van algoritmen voor paginavervanging onderscheiden: globale 
vervanging en lokale vervanging. Globale vervanging geeft een proces de mogelijk- 
heid een kader uit de groep van alle kaders te krijgen, zelfs als dat kader op dat 
moment aan een ander proces is toegewezen; het ene proces kan een kader van 
een ander proces afnemen. Lokale vervanging vereist dat elk proces slechts ka- 
ders uit zijn eigen groep van toegewezen kaders krijgt. 

Met een lokale vervangingsstrategie verandert het aantal kaders dat aan een 
proces is toegewezen niet. Met globale vervanging kan het voorkomen dat een 
proces alleen maar kaders kiest die aan andere processen zijn toegewezen, waar- 
door het aantal kaders dat eraan is toegewezen toeneemt (aangenomen dat andere 
processen voor vervanging geen kaders van dit proces kiezen). 

Een probleem bij een algoritme voor globale vervanging is dat een program- 
ma geen controle heeft over zijn eigen kans op paginafouten. De groep pagina’s 
die voor een proces in het geheugen verblijft hangt niet alleen af van het pagine- 
ringsgedrag van dat proces, maar ook van het pagineringsgedrag van andere 
processen. Daarom kan het prestatievermogen van een en hetzelfde programma 
geheel verschillend zijn (waarbij de tijd voor uitvoering de ene keer 0,5 seconde 
is en de volgende keer 10,3 seconden) louter en alleen door externe omstandighe- 
den. Dit is niet het geval met een lokaal vervangingsalgoritme. Met lokale vervan- 
ging wordt de groep pagina’s die voor een proces in het geheugen is alleen beïn- 
vloed door het pagineringsgedrag van dat proces zelf 


6.7.3 Algoritmen voor toewijzing 


De gemakkelijkste manier om m kaders over n processen te verdelen is iedereen 
een even groot aandeel te geven, te weten m/n kaders. Bijvoorbeeld, als er 93 
kaders en 5 processen zijn, zou elk proces 18 kaders krijgen. De overgebleven 3 
kaders zouden kunnen worden gebruikt als vrije-kaderbufferpot. Dit wordt gelij- 
ke toewijzing genoemd. 

Een alternatief spruit voort uit het inzicht dat verschillende processen ver- 
schillende hoeveelheden geheugen nodig zullen hebben. Als een klein programma 
van 10K van een student en een interactief database-programma van 127K de 
twee enige processen zijn die draaien in een systeem met 62 vrije kaders, is het 
niet erg zinvol om aan elk proces 31 kaders te geven. Het programma van de 
student heeft niet meer dan 10 kaders nodig, zodat de andere 21 pure verspilling 
betekenen. 

Om dit probleem op te lossen kunnen we gebruik maken van evenredige 
toewijzing. We wijzen aan elk proces beschikbaar geheugen toe overeenkomstig 
de grootte van het proces. Als de grootte in virtueel geheugen voor proces Py gelijk 
is aan gj, en we definiëren 


G= gj 
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dan wijzen we, als het totaal aantal beschikbare kaders m is, b; kaders toe aan 
proces p;, waarin b; bij benadering gelijk is aan 


b = g/G X m 


Natuurlijk moeten we van de bs gehele getallen maken, groter dan het mini- 
mumaantal kaders dat vereist is door de instructieset, waarbij de som niet groter 
mag zijn dan m. 

Met evenredige toewijzing zouden we 62 kaders over twee processen, één 
van 10 pagina’s en één van 127 pagina’s, verdelen door respectievelijk 4 kaders 
en 57 kaders toe te wijzen, aangezien 


10/137 Xx 62 = 4 
127/137 X 62 = 57 


Op deze manier maken beide processen gemeenschappelijk gebruik van de be- 
schikbare kaders overeenkomstig hun ’behoeften’, in plaats van op basis van gelij- 
ke toewijzing. 

In beide gevallen, gelijke en evenredige toewijzing, kan natuurlijk de toe- 
wijzing aan elk proces variëren afhankelijk van het multiprogrammeringsniveau. 
Als het multiprogrammeringsniveau wordt opgevoerd, zal elk proces een paar 
kaders verliezen om het geheugen te leveren dat voor het nieuwe proces nodig is. 
Daar staat tegenover dat, als het multiprogrammeringsniveau naar beneden gaat, 
de kaders die aan het vertrokken proces waren toegewezen nu over de over- 
blijvende processen verdeeld kunnen worden. 

U ziet dat zowel bij gelijke als bij evenredige toewijzing een proces met hoge 
prioriteit op dezelfde manier behandeld wordt als een proces met lage prioriteit. 
Wegens zijn hoge prioriteit kan het echter zijn dat we aan het proces met hoge 
prioriteit meer geheugen willen geven om de snelheid van zijn uitvoering op te 
voeren, ten koste van processen met lage prioriteit. 

Eén benaderingswijze is het gebruiken van het evenredige toewijzings- 
schema, waarbij de verhouding van de kaders dan niet afhangt van de relatieve 
grootte van elk programma maar van zijn prioriteit, of van een combinatie van 
grootte en prioriteit. 

Een andere benadering is dat processen met hoge prioriteit wordt toege- 
staan dat zij kaders voor vervanging afnemen van processen met lage prioriteit. 
Een proces kan een kader voor vervanging uit zijn eigen kaders krijgen, of uit de 
kaders van een proces dat lagere prioriteit heeft. Deze benadering geeft een pro- 
ces met hogere prioriteit de mogelijkheid zijn rantsoen van toegewezen kaders te 
verhogen ten koste van het proces met lagere prioriteit. 
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6.8 ‘Stampen’ (thrashing) 


Als het aantal kaders dat aan een proces met lage prioriteit is toegewezen be- 
neden het minimumaantal komt dat vereist is door de computerarchitectuur, 
moeten we de uitvoering van dat proces opschorten. We moeten dan de over- 
blijvende pagina’s uit het geheugen wegschrijven, waardoor al de eraan toegewe- 
zen kaders vrijkomen. Deze voorziening introduceert programmaverwisseling op 
het niveau van de CVE-werkindeling op middellange termijn. 

U moet eens letten op elk proces dat niet ’genoeg’ kaders heeft. Hoewel het 
technisch mogelijk is het aantal toegewezen kaders tot het minimum te beperken, 
is er een zeker (groter) aantal pagina’s dat actief gebruikt wordt. Als het proces 
dit aantal kaders niet heeft, zal het heel snel een paginafout veroorzaken. Op dit 
punt gekomen moet het een pagina vervangen. Daar echter al zijn pagina’s actief 
worden gebruikt, moet het een pagina vervangen die meteen weer nodig zal zijn. 
Als gevolg hiervan zal het heel snel weer een paginafout veroorzaken, en weer, en 
weer. Het programma blijft voortdurend paginafouten veroorzaken en pagina’s 
vervangen. Voor deze pagina’s veroorzaakt het dan weer paginafouten, zodat de- 
ze pagina’s meteen weer in het geheugen teruggebracht worden. 

Deze zeer hoge pagineringsactiviteit wordt ’stampen’ (Engels: thrashing) ge- 
noemd. Een proces is aan het stampen als het meer tijd met pagineren doorbrengt 
dan met de uitvoering. Stampen kan ernstige problemen voor het prestatiever- 
mogen veroorzaken. Let eens op het volgende scenario, dat gebaseerd is op het 
werkelijke gedrag van de eerste pagineringssystemen. 

Het besturingssysteem ziet toe op de CVE-gebruiksfactor. Als de CVE-ge- 
bruiksfactor te laag is wordt het multiprogrammeringsniveau opgevoerd door een 
nieuw proces in het systeem te brengen. Er wordt een algoritme voor globale 
paginavervanging gebruikt. Stel nu dat een proces in een nieuwe fase van zijn 
uitvoering komt en meer kaders nodig heeft. Het begint paginafouten te veroor- 
zaken en pagina’s weg te nemen van andere processen. Deze processen hebben 
die pagina’s echter nodig en dus gaan zij ook paginafouten veroorzaken en pa- 
gina’s van andere processen wegnemen. Deze paginerende processen moeten van 
het pagineerapparaat gebruik maken om pagina’s van en naar het geheugen over 
te brengen. Naarmate zij een wachtrij vormen voor het pagineerapparaat raakt 
de gereed-wachtrij leeg. Terwijl de processen voor het pagineerapparaat staan te 
wachten, gaat de CVE-gebruiksfactor naar beneden. 

De CVE-werkindeler ziet de CVE-gebruiksfactor omlaaggaan en gaat als 
gevolg daarvan het multiprogrammeringsniveau verhogen. De nieuwe processen 
proberen aan de slag te komen door pagina’s van draaiende processen weg te 
nemen. Dit is de oorzaak van meer paginafouten en een langere wachtrij voor 
het pagineerapparaat. Als gevolg daarvan daalt de CVE-gebruiksfactor nog meer 
en tracht de CVE-werkindeler het multiprogrammeringsniveau nog verder op te 
voeren. Nu gaat het systeem stampen en gaat zijn doorvoercapaciteit scherp om- 
laag. De kans op paginafouten neemt enorm toe. Het resultaat is dat de effectieve 
geheugentoegangstijd oploopt. Er komt geen werk af omdat de processen al hun 
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tijd aan paginering spenderen. 

Dit verschijnsel wordt geïllustreerd in figuur 6.15. De CVE-gebruiksfactor 
is uitgezet tegen het multiprogrammeringsniveau. Naarmate het multiprogram- 
meringsniveau toeneemt, neemt de CVE-gebruiksfactor ook toe, zij het lang- 
zamer, tot een maximum wordt bereikt. Neemt het multiprogrammeringsniveau 
nog verder toe, dan begint het systeem te stampen en gaat de CVE-gebruiksfactor 
scherp naar beneden. Op dit punt aangekomen moeten we, om de CVE-ge- 
bruiksfactor op te voeren en het stampen te laten ophouden, het multiprogram- 
meringsniveau verlagen. 

De effecten van stampen kunnen worden beperkt door een lokaal algoritme 
voor paginavervanging of een algoritme gebaseerd op prioriteit te gebruiken. Met 
lokale vervanging kan het ene proces als het begint te stampen geen kaders van 
een ander proces stelen, waardoor immers dit proces ook zou gaan stampen. Als 
processen beginnen te stampen zullen zij de meeste tijd in de wachtrij voor het 
pagineerapparaat doorbrengen. De gemiddelde tijd die nodig is voor het afhan- 
delen van een paginafout zal oplopen, zelfs voor een proces dat niet aan stampen 
onderhevig is. 


6.8.1 Het lokaliteitsprincipe 


Om stampen te voorkomen moeten we een proces zoveel kaders geven als het 
nodig heeft. Maar hoe weten we hoeveel kaders het ’nodig heeft’? Daarvoor zijn 
verschillende technieken. De werkset-strategie (die in paragraaf 6.8.2 besproken 
wordt) begint met te kijken naar wat een programma werkelijk gebruikt. Deze 
benaderingswijze bepaalt het lokaliteitsprincipe van de programma-uitvoering. 
Het lokaliteitsprincipe houdt in dat wanneer het programma wordt uitge- 
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voerd het van lokaliteit naar lokaliteit beweegt. Een lokaliteit is een groep pa- 
gina’s die tezamen intensief gebruikt worden (zie figuur 6.16). Een programma 
bestaat in het algemeen uit verschillende lokaliteiten die elkaar kunnen overlap- 
pen. 

Wanneer bijvoorbeeld een subroutine wordt aangeroepen, bepaalt deze een 
nieuwe lokaliteit. In deze lokaliteit worden geheugenverwijzingen gemaakt naar 
de instructies van de subroutine, zijn lokale variabelen en een deelgroep van de 
globale variabelen. Wanneer de subroutine verlaten wordt, verlaat het proces de- 
ze lokaliteit, omdat de lokale variabelen en instructies niet langer actief worden 
gebruikt. Het is mogelijk dat we later naar deze lokaliteit terugkeren. Zo zien we 
dat lokaliteiten worden bepaald door de structuur van het programma en zijn 
gegevensstructuren. Het lokaliteitsprincipe stelt dat alle programma’s deze fun- 
damentele structuur van geheugenverwijzingen zullen vertonen. 

Stel dat we genoeg kaders aan een proces toewijzen om zijn huidige loka- 
liteit te herbergen. Het proces zal via paginafouten al deze pagina’s in het geheu- 
gen brengen en dan geen paginafouten meer veroorzaken tot het van lokaliteit 
verandert. Als we minder kaders dan de grootte van de huidige lokaliteit toe- 
wijzen, zal het proces gaan stampen, daar het niet al de pagina’s die het actief 
gebruikt in het geheugen kan houden. 


6.8.2 Het werkset-model 


Het werkset-model is gebaseerd op het lokaliteitsprincipe. Dit model gebruikt een 
parameter, A, die het werkset-venster definieert. De gedachte hierachter is dat we 
de meest recente A verwijzingen willen onderzoeken. De groep pagina’s in de 
meest recente A paginaverwijzingen is de werkset (zie figuur 6.17). Als een pagina 
actief gebruikt wordt, zal het in de werkset voorkomen. Als de pagina niet langer 
gebruikt wordt zal het A verwijzingen nadat er voor het laatst naar verwezen werd 
uit de werkset verdwijnen. Aldus is de werkset een benadering van de lokaliteit 
van een programma. | 

Laten we als voorbeeld de reeks geheugenverwijzingen uit figuur 6.17 ne- 
men. Als A = 10 geheugenverwijzingen, dan is de werkset op tijdstip t {1, 2, 5, 
6, 7}. Op het tijdstip t is de werkset gewijzigd in (3, 4}. _ 

De nauwkeurigheid van de werkset hangt af van de keuze van A. Als A te 
klein is, zal deze niet de gehele werkset omvatten. Is A te groot, dan kan deze 
verschillende lokaliteiten overlappen. In het uiterste geval, als A oneindig is, is 
de werkset het gehele programma. Madnick en Donovan [1974] raden aan voor 
A ongeveer 10.000 verwijzingen te nemen. 

De belangrijkste eigenschap van de werkset is zijn grootte. Als we de werk- 
setgrootte, WSGi, voor elk proces in het systeem bepalen, dan kunnen we letten 


op 
B = 2 WSG: 
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Lokaliteit in een geheugenverwijzingspatroon. 
Overgenomen met toestemming van [Hatfield en Gerald 1971] 
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Het werkset-model 


waarin B de totale behoefte aan kaders voorstelt. Elk proces maakt actief gebruik 
van de pagina’s in zijn werkset. Zo heeft proces i WSG; kaders nodig. Als de 
totale behoefte aan kaders groter is, zullen sommige processen niet genoeg kaders 
hebben en dus gaan stampen. 

Het gebruik van het werkset-model is dan heel eenvoudig. Het besturings- 
systeem houdt de werkset van elk proces in de gaten en wijst een aantal kaders 
toe dat voldoende is met het oog op de grootte van de werkset van dat proces. 
Als er voldoende kaders over zijn, kan een ander proces op gang worden ge- 
bracht. Als de som van de werkset-grootten zo toeneemt dat het totale aantal 
beschikbare kaders overschreden wordt, zoekt het besturingssysteem een proces 
uit waarvan de uitvoering moet worden opgeschort. Zijn pagina’s worden weg- 
geschreven en zijn kaders worden nu aan andere processen toegewezen. Het opge- 
schorte proces kan later opnieuw gestart worden. 

Deze werkset-strategie voorkomt stampen, waarbij het multiprogram- 
meringsniveau zo hoog mogelijk gehouden wordt. Zo tracht deze strategie de 
CVE-gebruiksfactor te optimaliseren. 

De moeilijkheid met het werkset-model is het in het oog houden van de 
werkset. Het werkset-venster is een bewegend venster. Bij iedere geheugenver- 
wijzing verschijnt een nieuwe verwijzing aan het ene eind en valt de oudste verwij- 
zing aan het andere eind af. Een pagina bevindt zich in de werkset als er ergens 
binnen het werkset-venster naar verwezen wordt. We kunnen het werkset-model 
benaderen met een onderbreking door een tijdregister met een vast tijdsinterval 
en een referentiebit. 

Stel bijvoorbeeld dat A = 10.000 verwijzingen en dat we elke 5.000 verwij- 
zingen een onderbreking door een tijdregister kunnen veroorzaken. Wanneer we 
een onderbreking door het tijdregister krijgen, kopiëren we de waarden van de 
referentiebits voor alle pagina’s en zetten deze dan af. Dus als een paginafout 
optreedt, kunnen we de waarde van de referentiebit op dat moment en de waar- 
den van de twee bits in het geheugen onderzoeken om te bepalen of een pagina 
binnen de laatste 10.000 tot 15.000 verwijzingen werd gebruikt. Als de pagina 
gebruikt werd zal ten minste één van deze bits aanstaan. Als de pagina niet ge- 
bruikt werd zullen deze bits nul zijn. De pagina’s waarvoor ten minste één bit 
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aanstaat worden beschouwd tot de werkset te behoren. Let erop dat deze opzet 
niet geheel nauwkeurig is, omdat we niet kunnen zeggen waar binnen een interval 
van 5.000 verwijzingen een verwijzing plaats vond. We kunnen de onzekerheid 
verminderen door het aantal van onze geschiedenisbits en het aantal onder- 
brekingen groter te maken (bijvoorbeeld 10 bits met onderbrekingen na elke 
1.000 verwijzingen). De prijs voor het afhandelen van deze vaker voorkomende 
onderbrekingen zal echter dienovereenkomstig hoger zijn. 


6.8.3 Frequentie van paginafouten 


Het werkset-model is heel succesrijk en kennis van de werkset kan nuttig zijn 
voor voorpagineren (zie paragraaf 6.9.1), maar dit lijkt een nogal onhandige ma- 
nier om stampen onder controle te houden. De paginafoutfrequentie-strategie 
(PFF) is een directere aanpak. 

Het specifieke probleem is: hoe kunnen we stampen voorkomen? Stampen 
ontstaat door een grote PFF. Wanneer de PFF te groot wordt, weten we dat het 
proces meer kaders nodig heeft. Evenzo zou het proces, wanneer de PFF te klein 
is, wel eens te weinig kaders kunnen hebben. We kunnen voor de gewenste PFF 
een onder- en bovengrens vaststellen (zie figuur 6.18). Als de werkelijke PFF de 
bovengrens overschrijdt, wijzen we aan dat proces nog een kader toe; zakt de 
PFF beneden de ondergrens, dan nemen we van dat proces een kader weg. Zo 
kunnen we rechtstreeks de kans op paginafouten meten en onder controle houden 
om stampen te voorkomen. 

Evenals met de werkset-strategie is het mogelijk dat we de uitvoering van 
een proces moeten opschorten. Als de PFF omhooggaat en er zijn geen kaders 
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beschikbaar, moeten we een proces uitkiezen waarvan we de uitvoering opschor- 
ten. De vrijgekomen kaders worden dan aan processen met hoge PFF’s gegeven. 


6.9 Andere overwegingen 


De keuze van een algoritme voor paginavervanging en de keuze van een toe- 
wijzingsstrategie zijn de belangrijkste beslissingen die een pagineringssysteem 
moet nemen, maar er zijn nog tal van andere overwegingen. 


6.9.1 Voorpagineren 


Een duidelijke eigenschap van een systeem met zuiver pagineren op verzoek is het 
grote aantal paginafouten dat optreedt wanneer een programma wordt begonnen. 
Deze situatie is een gevolg van de poging om de aanvankelijke lokaliteit in het 
geheugen te krijgen. Hetzelfde kan op andere tijdstippen vóórkomen. Wanneer 
bijvoorbeeld bij programmaverwisseling een uit het geheugen weggezet proces 
opnieuw gestart wordt, bevinden al zijn pagina’s zich op het externe geheugen en 
moet elke pagina binnengebracht worden via een paginafout. Voorpagineren is 
een poging om dit hoge pagineringsniveau in het begin te voorkomen. Deze stra- 
tegie wil alle pagina’s die nodig zijn in één klap in het geheugen brengen. 

In een systeem dat bijvoorbeeld het werkset-model gebruikt, houden we bij 
elk proces een lijst bij van de pagina’s in zijn werkset. Als we de uitvoering van 
een proces moeten opschorten (wegens wachten op I/O of een gebrek aan vrije 
kaders), richten we ons op de werkset voor dat proces. Wanneer het proces hervat 
gaat worden (I/O is klaar of er zijn nu genoeg kaders), brengen we automatisch 
de gehele werkset terug in het geheugen voordat we het proces opnieuw starten. 

Voorpagineren kan in sommige gevallen een voordeel zijn. Het is gewoon 
de vraag of de prijs van voorpagineren lager is dan de prijs van het afhandelen 
van de daarmee overeenkomende paginafouten. Het kan heel goed zijn dat veel 
van de pagina’s die door voorpagineren in het geheugen worden teruggebracht 
niet worden gebruikt. Stel dat s pagina’s vooraf worden gepagineerd en dat er 
een fractie a van deze s pagina’s werkelijk wordt gebruikt (0<a<1). De vraag 
is of de prijs van de as uitgespaarde paginafouten wel of niet opweegt tegen de 
prijs van het voorpagineren van de (1-«)s pagina’s die niet nodig zijn. Als « dicht- 
bij nul ligt, verliest voorpagineren; ligt « dichtbij één, dan loont voorpagineren 
de moeite. 


6.9.2 Het blokkeren van I/O 


Bij gebruik van pagineren op verzoek is het soms noodzakelijk sommige pagina’s 
in het geheugen te blokkeren. Zo’n situatie treedt op bij I/O naar of van het 
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(virtuele) gebruikersgeheugen. I/O wordt dikwijls geïmplementeerd via een apar- 
te I/O-processor. Bijvoorbeeld, een besturingseenheid voor magneetband krijgt 
in het algemeen het aantal woorden (of bytes) dat moet worden overgebracht en 
een geheugenadres voor de buffer op (zie figuur 6.19). Wanneer het overbrengen 
klaar is wordt de CVE onderbroken. 

We moeten er zeker van zijn dat de volgende reeks gebeurtenissen niet op- 
treedt: Een proces doet een verzoek om I/O en wordt in een wachtrij voor dat 
randapparaat gezet. Intussen krijgen andere processen de CVE. Deze processen 
veroorzaken paginafouten en één ervan vervangt, bij gebruik van een algoritme 
voor globale paginavervanging, de pagina die de geheugenbuffer voor het wach- 
tende proces bevat. De pagina’s worden uit het geheugen weggeschreven. Enige 
tijd later, wanneer het verzoek om I/O naar het begin van de randapparaat- 
wachtrij opschuift, vindt de I/O plaats naar het gespecificeerde adres. Dit kader 
is nu echter in gebruik voor een andere pagina die tot een ander proces behoort. 

Er zijn twee veel voorkomende oplossingen voor dit probleem. De ene op- 
lossing is dat er nooit I/O wordt gedaan naar of van het gebruikersgeheugen. 
In plaats daarvan worden de gegevens altijd tussen het systeemgeheugen en het 
gebruikersgeheugen heen en weer gekopieerd. I/O heeft alleen plaats tussen het 
systeemgeheugen en het randapparaat. Om een blok naar magneetband te schrij- 
ven wordt het blok eerst naar het systeemgeheugen gekopieerd en dan naar de 
band geschreven. 

Dit extra kopiëren kan een onaanvaardbaar hoge overhead tot gevolg heb- 
ben. Een andere oplossing bestaat hierin dat de mogelijkheid wordt gegeven pa- 
gina’s in het geheugen te blokkeren. Daartoe wordt aan elk kader een blokkeerbit 
gehecht. Als het kader geblokkeerd is kan het niet geselecteerd worden om te 
worden vervangen. Met deze benadering worden, om een blok naar magneetband 
te schrijven, de pagina’s die het blok bevatten in het geheugen geblokkeerd. Het 
systeem kan dan gewoon doorgaan. Geblokkeerde pagina’s kunnen niet vervan- 
gen worden. Wanneer de I/O klaar is wordt de blokkering van deze pagina's 
opgeheven. 

Een ander gebruik van een blokkeerbit betreft de normale paginavervan- 
ging. De volgende reeks gebeurtenissen laat dat zien. Een proces met lage prio- 
riteit veroorzaakt een paginafout. Het pagineringssysteem selecteert een kader en 
brengt de benodigde pagina in het geheugen. Nu het gereed is om verder te gaan 
__komt het proces in de gereed-wachtrij en wacht op de CVE. Aangezien het een 
proces met lage prioriteit is, kan het zijn dat het geruime tijd niet door de CVE- 
werkindeler wordt geselecteerd. Terwijl het proces met lage prioriteit staat te 
wachten, veroorzaakt een proces met hoge prioriteit een paginafout. Bij het zoe- 
ken naar een vervanging ziet het pagineringssysteem een pagina die in het geheu- 
gen is, maar die niet gebruikt of gewijzigd is: de pagina die het proces met lage 
prioriteit zojuist naar binnen heeft gebracht. Deze pagina ziet eruit als een perfec- 
te kandidaat om te worden vervangen; hij is ongebruikt, hoeft dus niet te worden 
uitgeschreven, en is blijkbaar lange tijd niet gebruikt. 

De beslissing of het proces met hoge prioriteit in staat moet zijn het proces 
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met lage prioriteit te vervangen is een beleidskwestie. Uiteindelijk vertragen we 
gewoon het proces met lage prioriteit ten gunste van het proces met hoge prio- 
riteit. Daar staat tegenover dat al de moeite om de pagina van het proces met 
lage prioriteit naar binnen te brengen voor niets is geweest. Als we besluiten de 
vervanging van een pas binnengebrachte pagina te voorkómen tot deze ten minste 
eenmaal gebruikt kan worden, kunnen we de blokkeerbit gebruiken om dit beleid 
door te voeren. Wanneer een pagina voor vervanging geselecteerd wordt, wordt 
zijn blokkeerbit aangezet en dit blijft aan tot het proces dat de paginafout veroor- 
zaakte door het verdeelprogramma de CVE weer toegewezen krijgt. 

Het gebruik van een blokkeerbit kan evenwel gevaarlijk zijn, namelijk als 
het wordt aangezet zonder dat het ooit weer afgezet wordt. Zou deze situatie zich 
voordoen (wegens een fout in het besturingssysteem bijvoorbeeld), dan wordt het 
geblokkeerde kader onbruikbaar. 
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Figuur 6.19 
Kaders die voor I/O worden gebruikt moeten in het geheugen worden gehouden 
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6.9.3 Paginagrootte 


De ontwerpers van een besturingssysteem voor een bestaande machine kunnen 
zelden de paginagrootte zelf kiezen. Wanneer echter nieuwe machines worden 
ontworpen, moet een beslissing worden genomen aangaande de beste pagina- 
grootte. Zoals u zou verwachten, bestaat er geen enkele paginagrootte die de 
beste is. In plaats daarvan is er, op grond van een aantal factoren, voor diverse 
paginagrootten wel wat te zeggen. Paginagrootten zijn onveranderlijk machten 
van twee, in het algemeen tussen 256 (2%) en 4096 (2!2) bytes of woorden. 

Hoe kiezen we een paginagrootte? Eén punt van overweging is de grootte 
van de paginatabel. Voor een gegeven virtuele geheugenruimte doet het vermin- 
deren van de paginagrootte het aantal pagina’s, en daarmee de grootte van de 
paginatabel, toenemen. Voor een virtueel geheugen van 4 megawoorden (272), 
zouden er 16.384 pagina’s van 256 woorden zijn, maar slechts 1024 pagina’s van 
4096 woorden. Aangezien elk actief proces zijn eigen kopie van de paginatabel 
moet hebben, zien we dat een grote paginagrootte wenselijk is. 

Aan de andere kant wordt het geheugen beter benut met kleinere pagina’s. 
Als een programma geheugen toegewezen gekregen heeft, te beginnen bij positie 
00000 en doorgaande tot het zoveel heeft als het nodig heeft, is het onwaarschijn- 
lijk dat het programma precies op een paginagrens eindigt. Dus een deel van de 
laatste pagina moet worden toegewezen (omdat pagina’s de toewijzingseenheid 
vormen), maar is ongebruikt (interne fragmentatie). Als we aannemen dat de 
grootte van het programma en die van een pagina onafhankelijk zijn, kunnen we 
verwachten dat gemiddeld de helft van de laatste pagina wordt verspild. Dit ver- 
lies zou slechts 128 woorden bedragen voor een pagina van 256 woorden, maar 
2048 woorden voor een pagina van 4096 woorden. Om de interne fragmentatie 
zo klein mogelijk te maken hebben we een kleine paginagrootte nodig. 

Een ander probleem is de tijd die nodig is voor het lezen of wegschrijven 
van een pagina. De I/O-tijd (voor een randapparaat met vaste koppen) is opge- 
bouwd uit wachttijd en overbrengtijd. De overbrengtijd is evenredig met de hoe- 
veelheid die wordt overgebracht (dat is de paginagroote), een feit dat lijkt te 
pleiten voor een kleine paginagrootte. Denk er echter aan dat de wachttijd ge- 
woonlijk veel groter is dan de overbrengtijd. Bij een overbrengsnelheid van 
256.000 woorden per seconde duurt het slechts 2 msec om 512 woorden over te 
brengen. De wachttijd daarentegen kan misschien wel 8 msec bedragen. Van de 
totale I/O-tijd (10 msec) is derhalve 20% toe te schrijven aan de eigenlijke over- 
brenging. Het verkleinen van de paginagrootte tot 128 woorden brengt de totale 
I/O-tijd slechts terug van 10 naar 9 msec. Het verdubbelen van de paginagrootte 
doet de totale I/O-tijd toenemen tot slechts 12 msec. Het duurt 12 msec om een 
enkele pagina van 1024 woorden te lezen, maar 36 msec om dezelfde hoeveelheid 
te lezen in de vorm van vier pagina’s van elk 256 woorden. Dus de wens om de 
I/O-tijd zo klein mogelijk te houden pleit voor een grotere paginagrootte. 

Maar, met een kleinere paginagrootte, wordt de totale hoeveelheid I/O 
minder, omdat de lokaliteit beter zal worden. Een kleine paginagrootte zorgt 
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ervoor dat iedere pagina beter overeenkomt met de lokaliteit van het programma. 
Neem bijvoorbeeld een programma van 20K woorden, waarvan slechts de helft 
(10K) werkelijk tijdens een uitvoering wordt gebruikt. Als we slechts één grote 
pagina hebben, moeten we de gehele pagina binnenbrengen, in totaal 20K woor- 
den die moeten worden overgebracht en toegewezen. Als we pagina’s hadden van 
slechts één woord, dan hoefden we slechts de 10.000 woorden binnen te brengen 
die echt worden gebruikt, met als resultaat dat slechts 10K woorden worden 
overgebracht en toegewezen. Met een kleinere paginagrootte hebben we een beter 
oplossend vermogen, waardoor we het geheugen kunnen isoleren dat werkelijk 
nodig is. Met een grotere paginagrootte moeten we niet alleen dat wat nodig is 
overbrengen en toewijzen, maar ook al het andere dat toevallig in de pagina zit, 
of het nodig is of niet. Dus moet een kleinere paginagrootte resulteren in minder 
I/O en een kleinere totale hoeveelheid toegewezen geheugen. 

Aan de andere kant, heeft u opgemerkt dat met een paginagrootte van 1 
woord we een paginafout voor elk woord zouden hebben? Een programma van 
20K, dat slechts de helft van het geheugen gebruikt, zou slechts 1 paginafout 
genereren bij een paginagrootte van 20K, maar 10.000 paginafouten bij een pa- 
ginagrootte van 1 woord. Iedere paginafout genereert de grote hoeveelheid over- 
head nodig voor het veilig stellen van de registers, het vervangen van een pagina, 
het in de wachtrij staan voor het pagineerapparaat en het bijwerken van tabellen. 
Om het aantal paginafouten zo klein mogelijk te maken hebben we een grote 
paginagrootte nodig. 

Er zijn andere punten van overweging (zoals de relatie tussen de pagina- 
grootte en de sectorgrootte op het pagineerapparaat), maar er is voor het pro- 
bleem geen antwoord dat het beste is. Sommige factoren (interne fragmentatie, 
lokaliteit) pleiten voor een kleine paginagrootte, terwijl andere (omvang van ta- 
bellen, 1/O-tijd) weer pleiten voor een grote paginagrootte. Ter illustratie van het 
probleem: twee systemen staan twee verschillende paginagrootten toe. De Mul- 
tics-apparatuur (GE 645) staat pagina’s toe van óf 64 woorden óf 1024 woorden. 
De IBM 370 staat pagina’s toe van óf 2K óf 4K bytes. De moeilijkheid van het 
uitkiezen van een paginagrootte wordt nog eens geïllustreerd door het feit dat 
MVS op de IBM 370 voor pagina’s van 4K koos, terwijl VS/1 pagina’s van 2K 
nam. 


6.9.4 Programmastructuur 


Pagineren op verzoek wordt zo ontworpen dat het doorzichtig is voor het gebrui- 
kersprogramma. In veel gevallen is de gebruiker zich in het geheel niet bewust 
van het pagineringskarakter van het geheugen. In andere gevallen echter kan het 
prestatievermogen van het systeem worden verbeterd door zich ervan bewust te 
zijn dat het pagineren op verzoek bepalend voor het prestatievermogen is. 
Bijvoorbeeld, stel dat pagina’s 128 woorden groot zijn en dat een Pascal- 
programma werkt met een matrix (array) van 128 bij 128 die de beginwaarde nul 
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moet krijgen. De volgende code is dan kenmerkend: 


var A: array[1..128] of array[1..128] of integer; 


for j := 1 to 128 
do for i := 1 to 128 
do Ali] := 9; 


Deze code ziet er onschuldig genoeg uit, maar let erop dat de matrix rij voor rij 
is opgeslagen. Dat wil zeggen dat de matrix is opgeslagen als: A[1][1], A[1][2I. -.-, 
A{1][128], A[2][1], A[2][2], … A[128][128]. Voor pagina’s van 128 woorden neemt 
elke rij één pagina in beslag. Dus de code hierboven zet één woord in elke pagina 
op nul, dan een tweede woord in elke pagina, enzovoort, met als gevolg 128 X 
128 = 16.384 paginaverwijzingen met mogelijke paginafouten. Door echter de 
code te wijzigen in 


var A: array[1..128] of array[1..128] of integer; 


for i := 1 to 128 
do for j := 1 to 128 
do A[i][/] := 9; 


worden alle woorden van de ene pagina op nul gezet voordat begonnen wordt 
aan de volgende pagina, waardoor het aantal mogelijke paginafouten tot 128 
wordt teruggebracht. 

Het zorgvuldig uitkiezen van gegevens- en programmastructuren kan de 
lokaliteit verhogen, en dus de PFF en het aantal pagina’s in de werkset vermin- 
deren. Een stapel heeft een goede lokaliteit, omdat altijd toegang verschaft wordt 
tot het eerste element. Een hash-tabel daarentegen is erop gemaakt dat de verwij- 
zingen kris-kras verspreid zijn, wat een slechte lokaliteit met zich meebrengt. 

In een later stadium kunnen het compileer- en het laadprogramma een aan- 
zienlijk effect op paginering hebben. Het scheiden van de code en de gegevens 
en het genereren van herbetreedbare (re-entrant) code betekent dat code-pagina’s 
alleen-uitleesbaar (read only) zijn en dus nooit gewijzigd kunnen zijn. Ongewij- 
zigde pagina’s hoeven bij vervanging niet te worden weggeschreven. Het laadpro- 
gramma kan vermijden dat routines over paginagrenzen heen worden geplaatst 
en het kan elke routine volledig binnen één pagina houden. Routines die elkaar 
vaak aanroepen kunnen in dezelfde pagina worden gehouden. Dit is een variant 
van het schap-opbergprobleem in de besliskunde: probeer de laadsegmenten met 
variabele grootte in de pagina’s met vaste grootte zo op te bergen dat verwijzin- 
gen buiten de paginagrenzen tot een minimum beperkt worden. Zo’n benadering 
is bijzonder nuttig wannneer pagina’s erg groot zijn. 
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6.9.5 Hiërarchie van geheugens 


We moeten erop wijzen dat onze bespreking zich heeft toegespitst op slechts 
één niveau van wat in de meeste systemen een hiërarchie van geheugens is. Veel 
computers beschikken nu over een zeer snel tussengeheugen (Engels: cache) tus- 
sen de registers en het hoofdgeheugen. Bij een geheugentoegang wordt de inhoud 
van de desbetreffende positie, en die van zijn buren, naar het tussengeheugen 
gekopieerd. Als een andere verwijzing naar deze posities wordt gemaakt, kan de 
inhoud rechtstreeks uit het tussengeheugen worden opgehaald, zonder dat we 
naar het langzamere hoofdgeheugen hoeven te gaan. Voor een tussengeheugen 
met een redelijke omvang is een trefkans van 80% gebruikelijk. 

Als een historische bijkomstigheid vermelden we dat de eerste paginerings- 
computer de Atlas-computer was. Het hoofdgeheugen was een trommel van 96K. 
Trommelgeheugens waren tamelijk gebruikelijk aan het eind van de jaren ’50, en 
werden ook gebruikt op de IBM 650. De Atlas had een kleine hoeveelheid (16K 
woorden) nieuw, sneller geheugen dat magnetisch kernengeheugen werd ge- 
noemd. Dit was toen nog in een experimenteel stadium en zeer kostbaar. Het 
kernengeheugen werd gebruikt als een tussengeheugen voor het langzamere trom- 
melgeheugen. Men ontwikkelde pagineringstechnieken om het beheer van het 
tussengeheugen te implementeren. 

Wanneer we dit gezichtspunt wat uitbreiden, zien we dat intern program- 
meerbare registers, zoals indexregisters en optelregisters, een snel tussengeheugen 
vormen voor het hoofdgeheugen. De programmeur (of het compileerprogramma) 
implementeert de toewijzing van registers (of pagina’s) en bijbehorende vervan- 
gingsalgoritmen om uit te maken welke informatie in het primaire geheugen (re- 
gisters) en wat in het hulpgeheugen (hoofdgeheugen) gehouden kan worden. Het 
algoritme voor optimale paginavervanging kan hierbij vaak worden gebruikt, om- 
dat de programmeur of compiler vooruit kan kijken om te zien wat er in de 
toekomst nodig zal zijn. 

Als we de andere kant uit kijken, kunnen we het bestandssysteem zien als 
een hulpgeheugen voor het pagineerapparaat. Bestanden worden uit het be- 
standssysteem overgebracht naar het pagineerapparaat wanneer naar die bestan- 
den wordt verwezen (overbrenging op verzoek). Het bestandssysteem kan zelf 
verschillende geheugenniveaus hebben. Het snellere (maar beperktere) schijven- 
geheugen kan worden geholpen door een groter (maar langzamer) magneetband- 
geheugen. Om overbrenging tussen deze twee geheugenniveaus wordt meestal ex- 
pliciet verzocht, maar veel systemen archiveren nu automatisch een bestand dat 
lange tijd (een maand) niet gebruikt is en zullen dit dan automatisch weer naar 
schijf terughalen wanneer er de volgende maal naar verwezen wordt. 

Als we een stapje terug doen, kunnen we een grote verscheidenheid aan 
opslagruimte (geheugen) in een computersysteem zien, die in een hiërarchische 
structuur kan worden georganiseerd (zie figuur 6.20). De hogere niveaus zijn 
duur, maar zeer snel. Naarmate we lager komen in de hiërarchie gaat de prijs per 
bit naar beneden, terwijl de toegangstijd omhooggaat en de hoeveelheid geheugen 
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Figuur 6.20 
Hiërarchie van geheugens 


met elk niveau toeneemt. De beweging van informatie tussen de niveaus kan 
zowel expliciet als impliciet zijn. Algoritmen voor paginering zijn voor veel van 
deze soorten overbrenging geschikt. 

Deze kijk op het geheugen voerde tot zijn natuurlijke afronding in het Mul- 
tics-systeem. Multics heeft een zeer grote gesegmenteerde adresruimte. De seg- 
menten zijn benoemd, en alle bestanden zijn segmenten. Aldus zijn er geen ex- 
pliciete I/O-commando’s nodig. Men kan tot een bestand toegang krijgen door 
de bestandsnaam als een segmentnaam te specificeren en rechtstreeks uit het 
segment te laden of erin op te slaan. De verwijzing veroorzaakt dan een segment- 
fout (en vervolgens een paginafout) voor het overbrengen van de gewenste infor- 
matie vanuit het bestandssysteem naar het geheugen. 
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6.10 Samenvatting 


Het is wenselijk dat men in staat is een proces uit te voeren waarvan de logische 
adresruimte groter is dan de beschikbare fysieke adresruimte. De programmeur 
kan zo’n proces uitvoerbaar maken door het met gebruikmaking van overlappen- 
de programmasegmenten (overlays) te herstructureren, maar dit is in het alge- 
meen eem moeilijk programmeerkarwei. Virtueel geheugen is een techniek die de 
mogelijkheid geeft dat een grote logische adresruimte wordt afgebeeld op een 
kleiner fysiek geheugen. Virtueel geheugen geeft de mogelijkheid van het draaien 
van grote programma’s en het opvoeren van het multiprogrammeringsniveau, 
waardoor de CVE-gebruiksfactor omhooggaat. 

Zuiver pagineren op verzoek brengt nooit een pagina in het geheugen totdat 
werkelijk daarnaar wordt verwezen. De eerste verwijzing veroorzaakt een pagina- 
fout voor de residente monitor van het besturingssysteem. Het besturingssysteem 
raadpleegt een interne tabel om te bepalen waar op het externe geheugen de 
pagina zich bevindt. Dan zoekt het een vrij kader op en leest het de pagina in 
vanaf het externe geheugen. De paginatabel wordt bijgewerkt om deze verande- 
ring weer te geven, waarna de instructie die de paginafout veroorzaakte opnieuw 
wordt gestart. Deze benaderingswijze biedt de mogelijkheid dat een programma 
draait zelfs als het totale geheugenbeeld daarvan zich niet in het interne geheugen 
bevindt. Zolang de kans op paginafouten redelijk laag is, is het prestatievermogen 
aanvaardbaar. 

Van pagineren op verzoek kan gebruik worden gemaakt om het aantal ka- 
ders dat aan een proces is toegewezen te verminderen. Met deze opzet kan het 
multiprogrammeringsniveau worden verhoogd (waardoor de mogelijkheid ge- 
boden wordt dat meer processen gelijktijdig voor uitvoering beschikbaar zijn) en 
tevens, dat hopen we althans, gaat daarmee de CVE-gebruiksfactor van het sys- 
teem omhoog. Hierdoor kunnen ook programma’s draaien zelfs als hun geheu- 
geneisen de totale hoeveelheid beschikbaar fysiek geheugen overschrijden. Zulke 
programma’s draaien in het virtuele geheugen. 

Als het totaal van geheugeneisen het fysieke geheugen overschrijdt, kan het 
noodzakelijk zijn pagina’s uit het geheugen te vervangen, om kaders voor nieuwe 
pagina’s vrij te maken. Men gebruikt diverse algoritmen voor paginavervanging. 
FIFO is gemakkelijk te programmeren, maar gaat mank aan de anomalie van 
Belady. Optimale paginavervanging vereist kennis van de toekomst. Minst-Re- 
cent-Gebruikt (MRG) is een benadering van optimaal, maar ook dit kan moeilijk 
te implementeren zijn. De meeste algoritmen voor paginavervanging, zoals ’twee- 
de-kans’ zijn benaderingen van MRG. 

Behalve een algoritme voor paginavervanging is ook een toewijzingsbeleid 
nodig. De toewijzing kan vast zijn, in de trant van lokale paginavervanging, of 
dynamisch, in de geest van globale paginavervanging. Het werkset-model gaat 
uit van de veronderstelling dat programma’s in lokaliteiten werken. De werkset 
is de groep van pagina’s die tot de huidige lokaliteit behoren. In overeenstemming 
daarmee moeten aan ieder proces voldoende kaders voor zijn huidige werkset 
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worden toegewezen. 

Als een proces niet genoeg kaders voor zijn huidige werkset heeft, gaat het | 
stampen. Procesverwisseling en -werkindeling kunnen nodig zijn om voldoende 
kaders aan een proces te geven om stampen te vermijden. 

Behalve de hoofdproblemen van paginavervanging en kadertoewijzing, ver- 
eist het juiste ontwerp van een pagineringssysteem dat ook de paginagrootte, de 
I/O, het blokkeren ten behoeve van I/O, voorpagineren, de programmastructuur 
en andere zaken aandacht krijgen. Men kan virtueel geheugen zien als één niveau 
in een hiërarchie van geheugenniveaus in een computersysteem. Ieder niveau 
heeft zijn eigen parameters voor toegangstijd, grootte en prijs. 


Opgaven 


6.1 Welke betrekking bestaat er tussen de keuze van de structuur van een 
bestandssysteem en het virtuele geheugen van het systeem? 


6.2 Wanneer treden paginafouten op? Beschrijf de acties die door het bestu- 
ringssysteem worden ondernomen wanneer er een paginafout optreedt. 


6.3 Zou een trommel of zou een schijf beter zijn als pagineerapparaat? 


6.4 Stel dat u een reeks paginaverwijzingen heeft voor een proces met m 
kaders (aanvankelijk allemaal leeg). De paginaverwijzingsreeks heeft de 
lengte p en er komen n afzonderlijke paginanummers in voor. Het doet 
er niet toe welk algoritme voor paginavervanging wordt gebruikt. 

a. Wat is een ondergrens voor het aantal paginafouten? 
b. Wat is een bovengrens voor het aantal paginafouten? 


6.5 Evenals we paginering op verzoek hebben, zo kunnen we ook segmen- 
tering op verzoek hebben. We hebben dan een algoritme voor segment- 
vervanging nodig (gelijkend op een algoritme voor paginavervanging). 
Beschrijf een redelijk algoritme voor segmentvervanging. Welke proble- 
men treden er op bij segmentvervanging die er niet zijn bij paginavervan- 


ging? 


6.6 Welke van de volgende programmeertechnieken en structuren zijn ’goed’ 
voor een omgeving met pagineren op verzoek, en welke zijn ‘niet goed’? 

. Stapel. 

. Hash-symbolentabel. 

. Sequentieel zoeken. 

. Binair zoeken. 

. Zuivere (re-entrant) code. 

. Vectorbewerkingen. 

. Indirecte adressering. 
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Beschouw de volgende algoritmen voor paginavervanging: 
a. MRG. | 
b. FIFO. 

c. Optimaal. 

d. Tweede kans’. 


Rangschik deze algoritmen van slecht tot perfect, overeenkomstig hun 
kans op paginafouten. Verdeel de algoritmen in die welke de anomalie 
van Belady vertonen en die welke dat niet doen. 


Een zekere computer geeft zijn gebruikers een virtuele geheugenruimte 
van 2% woorden. De computer heeft 2!8 woorden fysiek geheugen. Het 
virtuele geheugen is geïmplementeerd met behulp van paginering en de 
paginagrootte is 256 woorden. Een gebruikersprogramma genereert het 
virtuele adres 11123456 (octaal getal). Leg uit hoe het systeem de daarbij 
behorende fysieke positie bepaalt. Maak een onderscheid tussen pro- 
grammatuur- en apparatuurbewerkingen. 


Beschouw de volgende reeks geheugenverwijzingen van een programma 
dat uit 460 woorden bestaat: 


10, 11, 104, 170, 73, 309, 185, 245, 246, 434, 458, 364 


@ Geef de verwijzingsreeks, uitgaande van een paginagrootte van 100 
woorden. 

@ Onderzoek de kans op paginafouten voor deze verwijzingsreeks, ervan 
uitgaande dat 200 woorden hoofdgeheugen beschikbaar zijn voor het 
programma en dat het algoritme voor paginavervanging FIFO is. 

@ Wat zou de kans op paginafouten zijn als we een MRG-algoritme 
gebruikten? | 

@ Wat is de kans op paginafouten voor het optimale vervangingsalgorit- 
me? 


Stel dat uw vervangingsbeleid (in een gepagineerd systeem) bestaat in 
het regelmatig onderzoeken van elke pagina en deze te vervangen als hij 
sinds het laatste onderzoek niet gebruikt was. Wat zou u winnen en wat 
zou u verliezen door dit beleid te gebruiken in plaats van, zeg, MRG of 
‘Tweede kans’? 


Beschouw een pagineringssysteem met een pagineertrommel met 4 mil- 
joen woorden geheugen en een gemiddelde toegangs- en overbrengtijd 
van 5 milliseconden, en een gepagineerd kernengeheugen van 262.144 
woorden met een toegangstijd van 2 microseconden. Als we willen dat 
ons pagineringssysteem er voor de gebruiker uitziet als een geheugen van 
4 miljoen woorden met een (gemiddelde) toegangstijd van 4 microsecon- 
den, welk percentage van de geheugentoegangen moet dan plaatsvinden 
zonder dat er een paginafout optreedt? 
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Wanneer in een computersysteem virtueel geheugen is geïmplementeerd, 
dan zijn aan deze techniek zekere nadelen en ook zekere voordelen ver- 
bonden. Schrijf de nadelen en de voordelen op. Is het mogelijk dat de 
nadelen de voordelen te boven gaan? Welke maatregelen kan men nemen 
om te garanderen dat dit niet gebeurt? 


Beschouw een systeem met paginering op verzoek. De gemeten ge- 
bruiksfactoren zijn: 


CVE-gebruiksfactor 20% 
pagineertrommel 99,7% 
andere randapparatuur 5% 


Welke (zo die er zijn) van de volgende maatregelen zullen (waarschijn- 
lijk) de CVE-gebruiksfactor verbeteren? Waarom? 

a. Neem een snellere CVE. 

b. Neem een snellere pagineertrommel. 

c. Voer het multiprogrammeringsniveau op. 

d. Breng het multiprogrammeringsniveau omlaag. 

e. Neem snellere overige randapparatuur. 


Een besturingssysteem ondersteunt een gepagineerd virtueel geheugen, 

waarbij het een centrale verwerkingseenheid gebruikt met een cyclustijd 

van 1 microseconde. Pagina’s bestaan uit 1000 woorden en het pagineer- 

apparaat is een trommel die ronddraait met een snelheid van 3000 om- 

wentelingen per minuut en die 1.000.000 woorden per seconde over- 

brengt. Van het systeem werden de volgende statistische metingen ver- 

kregen: 

@ 0,1% van alle uitgevoerde instructies verwees naar een pagina buiten 
de huidige pagina. 

@ Van de instructies die naar een andere pagina verwezen, verwees 80% 
naar een pagina die al in het geheugen was. 

@ Wanneer een nieuwe pagina nodig was, was in 50% van de gevallen 
de vervangen pagina gewijzigd. 


Bereken de effectieve instructietijd (de gemiddelde tijd die nodig is voor 
het uitvoeren van een instructie) op dit systeem, ervan uitgaande dat 
slechts één programma op het systeem draait en dat de CVE tijdens de 
overbrenging van en naar de trommel zonder werk zit. 


Stel dat we een algoritme voor paginavervanging willen gebruiken dat 
een referentiebit nodig heeft (zoals voor Tweede kans’ of het werkset- 
model), maar de apparatuur heeft niet zo’n bit. Kunt u schetsen hoe u 
een referentiebit zou kunnen simuleren, zelfs als de apparatuur er geen 
heeft, of is dit niet mogelijk? Als het mogelijk is, wat zou dan de prijs 
zijn die men ervoor betaalt? 
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We hebben een nieuw algoritme voor paginavervanging ontworpen dat 
nogal complex is, maar we denken dat het optimaal is. In enkele proefex- 
perimenten treedt de anomalie van Belady op. Is het nieuwe algoritme 
optimaal? 


Beschouw de matrix (array) A: 
var A: array[ 1100] of array{ 1.100] of integer; 


waarin A[1][1] zich in positie 200 bevindt, in een pagineringssysteem met 
pagina’s van 200 woorden. Een programmaatje voor bewerking van de 
matrix bevindt zich in positie 0 (posities 0-199), zodat elke instructie 
wordt opgehaald uit pagina 0. 

Hoeveel paginafouten worden, met drie kaders, gegenereerd voor 
de volgende lussen om de matrix te initialiseren, waarbij we aannemen 
dat we gebruik maken van MRG-vervanging, dat kader 1 het programma 
bevat en dat de andere twee kaders in het begin leeg zijn. 


a. for j := 1 to 100 
do for i := 1 to 100 
do Alillj] := 0; 


b. for i := 1 to 100 
do for j := 1 to 100 
do A[i][j] := 0; 


Beschouw de volgende reeks paginaverwijzingen: 
RNR By 2, 0, Fy © NEI 236 


Hoeveel paginafouten zouden er optreden bij de volgende vervangingsal- 
goritmen, aangenomen dat er 1, 2, 3, 4, 5, 6 of 7 kaders zijn? Denk eraan 
dat in het begin alle kaders leeg zijn, dus uw eerste pagina’s zullen alle 
één voor één een paginafout opleveren. 

e MRG. 

@ FIFO. 

@ Optimaal. 


Segmentering lijkt erg op paginering, maar dan met ’pagina’s’ van veran- 
derlijke grootte. Definieer twee algoritmen voor segmentvervanging die 
op de schema’s van FIFO- en MRG-paginavervanging zijn gebaseerd. 
Denk eraan dat het segment dat geselecteerd wordt om te worden ver- 
vangen misschien niet groot genoeg is om voldoende aaneengesloten po- 
sities voor het benodigde segment over te laten; segmenten hebben im- 
mers niet dezelfde grootte. Beschouw strategieën voor systemen waarbij 
segmenten niet verplaatst kunnen worden en systemen waarbij dat wel 
kan. | 
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Beschouw een systeem met paginering op verzoek, met een pagineer- 
trommel met een gemiddelde toegangs- en overbrengtijd van 5 milli- 
seconden. Adressen worden vertaald via een paginatabel in het hoofdge- 
heugen, met een toegangstijd van 1 microseconde per geheugentoegang. 
Dus iedere geheugenverwijzing via de paginatabel vereist twee toegan- 
gen. Om deze tijd te verbeteren is een associatief geheugen toegevoegd 
dat de toegangstijd terugbrengt tot één geheugenverwijzing als de pa- 
ginatabel in het associatieve geheugen is. 

= Als we aannemen dat 80% van de toegangen in het associatieve 
geheugen wordt aangetroffen en dat van de resterende toegangen 10% 
(ofwel 2% van het totale aantal toegangen) paginafouten veroorzaakt, 
wat is dan de effectieve geheugentoegangstijd? 


Beschouw een systeem met een kernengeheugen van 1 microseconde en 

een secundair geheugen op trommel met een gemiddelde trommelwacht- 

tijd van 5 microseconden en een overbrengsnelheid van een miljoen 
woorden per seconde. 

a. Wat is de effectieve toegangstijd voor een paginagrootte p en een kans 
op paginafouten x (0<x<1)? 

b. Stel dat de kans op paginafouten omgekeerd exponentieel varieert 
met de paginagrootte volgens de formule x = e-#/500, Dus hoe groter 
de paginagrootte, hoe kleiner de kans op paginafouten. Welke pagina- 
grootte geeft de kleinst mogelijke effectieve toegangstijd? 


Stel dat we een geheugen met pagineren op verzoek hebben. De pagina- 
tabel wordt in registers bewaard. Het duurt 8 milliseconden om een pa- 
ginafout af te handelen als een leeg kader beschikbaar is of als de vervan- 
gen pagina niet gewijzigd is, en 20 milliseconden als de pagina gewijzigd 
is. De geheugentoegangstijd is 1 microseconde. 

Neem aan dat de te vervangen pagina in 70% van de gevallen ge- 
wijzigd is. Wat is dan de grootst mogelijke kans op paginafouten die nog 
getolereerd kan worden om de effectieve toegangstijd niet boven de 2 
microseconden te laten uitkomen? 


Een algoritme voor paginavervanging moet het aantal paginafouten zo 
klein mogelijk houden. Deze minimalisering kan worden bereikt door 
veel gebruikte pagina’s gelijkelijk over het gehele geheugen te verdelen 
in plaats van ze te laten wedijveren om een klein aantal kaders. We kun- 
nen aan elk paginakader een teller koppelen die het aantal pagina’s dat 
met dat kader verbonden is telt. Voor het vervangen van een pagina 
zoeken we dan het kader uit met de kleinste waarde in de teller. 
a. Definieer een algoritme voor paginavervanging dat van deze grond- 
gedachte gebruik maakt. Houd speciaal met de volgende problemen 
rekening: 
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1. De beginwaarden van de tellers. 

2. Wanneer tellers worden opgehoogd. 

3. Wanneer tellers worden verlaagd. 

4. Hoe de te vervangen pagina wordt geselecteerd. 


b. Hoeveel paginafouten treden er op voor uw algoritme voor paginaver- 
vanging bij de volgende verwijzingsreeks en vier paginakaders? 


1534534 3, 6,.7,.8, 7, 8, 9, 7, 8, 9, 54 31 4, 2 


c. Wat is het minimumaantal paginafouten voor een optimale strategie 
voor paginavervanging voor de verwijzingsreeks in (b) met vier pa- 
ginakaders? 


Is het noodzakelijk een pagina van een proces iedere keer dat deze wordt 
weggeschreven op dezelfde plaats op de trommel (of schijf) terug te 
schrijven? Indien niet, leg dan uit onder welke omstandigheden dit niet 
noodzakelijk is. 


Wat is de oorzaak van stampen? Hoe ontdekt het systeem dit, en wan- 
neer het eenmaal ontdekt is, wat kan het systeem dan doen om dit te 
verhelpen? 


Als een normale consument heeft u langzamerhand heel wat dingen ver- 
gaard. Omdat u een klein huis heeft slaat u het een en ander op zolder 
op, maar nu denkt u erover een opslagruimte te huren. Dit zou u drie 
opslagplaatsen geven: het huis (actief gebruik), de zolder (gemakkelijk 
toegankelijke opbergruimte) en de opslagruimte (moeilijk toegankelijke 
opbergruimte). Stel een schema op volgens welk u besluit wat er op zol- 
der en wat er in de opslagruimte bewaard moet worden. 


We hebben een besturingssysteem voor een machine die een basis- en 
een limietregister gebruikt, maar we hebben de machine gewijzigd zodat 
deze ook een paginatabel heeft. Kunnen de paginatabellen zo worden 
opgezet dat het basis- en het limietregister kunnen worden gesimuleerd? 
Hoe moet dit, of waarom kan het niet? 


IBM heeft een Groot Kernengeheugen (Large Core Storage, LCS) dat 
een betrekkelijk goedkoop, betrekkelijk langzaam geheugen is. Ongelijk 
aan het Uitgebreide Kernengeheugen (Extended Core Storage, ECS) van 
CDC staat LCS rechtstreekse uitvoering van programma’s daarin toe. 
Directe toegang tot een woord duurt ongeveer 4 microseconden, in te- 
genstelling tot 1 microseconde voor het primaire kernengeheugen. Stel 
dat het geheugen in pagina’s van 256 woorden kan worden verdeeld. 
Hoewel directe toegang tot LCS een toegangstijd geeft van 4 microsecon- 
den, kan een pagina aaneengesloten geheugen naar het hoofdgeheugen 
worden overgebracht in slechts 259 microseconden (4 voor de eerste en 
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dan 1 microseconde voor elke volgende positie). We denken aan twee 

methoden voor geheugenbeheer: (i) paginering in het hoofdgeheugen 

vanuit LCS, of (ii) rechtstreekse uitvoering in LCS. Bereken de effectieve 

toegangstijd voor elk van beide methoden voor de volgende soorten pro- 

gramma’s. Voor welke kans op paginafouten zou welk schema gebruikt 

worden? 

a. Een programma met goede lokaliteit en een kans op paginafouten van 
1%. 

b. Een programma met slechte lokaliteit en een kans op paginafouten 
van 37%. 


Beschouw een computersysteem met pagineren op verzoek dat gebruik 
maakt van een pagineertrommel, globale MRG-vervanging, en een ka- 
dertoewijzingsbeleid dat kaders gelijkelijk over de processen verdeelt 
(dat wil zeggen, dat als er m kaders en n processen zijn, elk proces m/n 
kaders krijgt). Het multiprogrammeringsniveau is momenteel vastgesteld 
op vier. Van een recente meting van de gebruiksfactoren van de CVE en 
de pagineertrommel waren de resultaten als volgt: 

a. CVE-gebruiksfactor 13%; trommel-gebruiksfactor 97%. 

b. CVE-gebruiksfactor 87%; trommel-gebruiksfactor 3%. 

c. CVE-gebruiksfactor 13%; trommel-gebruiksfactor 3%. 


Wat gebeurt er in elk van deze gevallen? Kan het multiprogrammerings- 
niveau worden opgevoerd om een hogere CVE-gebruiksfactor te krijgen? 
Helpt het pagineren? 


Beschouw een machine met de volgende pagineringsapparatuur. Er zijn 
32 paginakaders voor pagina’s van 512 woorden. Paginatabellen hebben 
32 ingangen en worden in het geheugen gehouden, te beginnen bij adres- 
sen die veelvouden van 32 zijn (zo dat de vijf minst significante bits nul 
zijn). Twee speciale registers, GPT en SPT, wijzen naar respectievelijk 
de Gebruikers-Pagina-Tabel en de Systeem-Pagina-Tabel. In de gebrui- 
kermodus wordt GPT gebruikt voor adresvertaling tot een paginafout of 
andere onderbreking optreedt, dan wordt de programmateller opgesla- 
gen in het adres dat in het OA-register (Onderbrekings-Adresregister) 
staat en wordt de uitvoering vervolgd op het adres OA + 1 in de systeem- 
modus, met gebruikmaking van de paginatabellen waarnaar SPT wijst. 
Als een onderbreking optreedt tijdens de uitvoering in de systeem-modus 
wordt dezelfde procedure gevolgd. Iedere paginatabelingang gebruikt de 
tekenbit als de geldig/ongeldig-bit (0 = in het geheugen, 1 = niet in het 
geheugen), en de vijftien minst significante bits (woorden bestaan uit 
zestien bits) specificeren het beginadres van de pagina. De negen minst 
significante bits moeten nul zijn (alle pagina’s beginnen op een veelvoud 
van de paginagrootte, 512). Iedere geheugentoegang wordt vertaald door 
een van de paginatabellen, GPT of SPT, afhankelijk van de modus van 
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de CVE: gebruiker- of systeem-modus. 

a. Wat gebeurt er als de pagina voor het adres in OA niet in het geheu- 
gen is? 

b. Hoe kan het besturingssysteem het geheugen in absolute zin adres- 
seren (dat wil zeggen zonder vertaling door een paginatabel)? 


Bibliografische verwijzingen 


Pagineren op verzoek werd voor het eerst gebruikt in het Atlas-systeem, geïmple- 
menteerd op de MUSE-computer van de Universiteit van Manchester rond het 
jaar 1960 [Kilburn et al. 1961, 1962]. Een ander systeem met pagineren op ver- 
zoek uit de begintijd was Multics, geïmplementeerd op het GE 645 systeem [Da- 
ley en Dennis 1968; Bensoussan et al. 1972; Organick 1972]. Andere systemen 
met pagineren op verzoek uit de begindagen zijn onder andere het THE-bestu- 
ringssysteem [Bron 1972] (waarin de paginering in de programmatuur werd geïm- 
plementeerd) en het TENEX-besturingssysteem [Bobrow et al. 1972]. 

Belady [et al. 1969] was de eerste die opmerkte dat het FIFO-vervangingsal- 
goritme de anomalie kan vertonen die naar hem genoemd is. Mattson et al. [1970] 
toonden aan dat stapel-algoritmen niet aan de anomalie van Belady onderhevig 
zijn. 

Het algoritme voor optimale paginavervanging is te danken aan Belady 
[1966]. Dat het optimaal is werd bewezen door Mattson et al. [1970]. Belady’s 
optimale algoritme geldt voor een vaste toewijzing; Prieve en Fabry [1976] heb- 
ben een optimaal algoritme voor het geval dat de toewijzing kan variéren. Gus- 
tavson [1968], Denning [1970], Colin [1971] en Aho et al. [1971] bespraken diverse 
algoritmen voor paginavervanging. Belady [1966], Mattson et al. [1970], Coffman 
en Varian [1968] en Belady en Kuehner [1969] vergeleken algoritmen voor pa- 
ginavervanging. Comeau [1967], Brawn en Gustavson [1968], McKellar en Coff- 
man [1969], Sayre [1969] en Winograd et al. [1971] hielden zich in het bijzonder 
bezig met kwesties aangaande het prestatievermogen. 

‘Stampen’ (thrashing) werd besproken door Denning [1968] en Alderson et 
al. [1972]. Het werkset-model hebben we te danken aan Denning [1968]. Denning 
[1970, 1980a], Doherty [1970], Denning en Schwartz [1972] en Coffman en Ryan 
[1972] gingen door met het werken aan het werkset-model. De methode voor het 
meten van de kans op paginafouten is te danken aan Wulf [1969] die met succes 
deze techniek toepaste op het Burroughs B5500 computersysteem. Operdeck en 
Chu [1974] bespreken ook het algoritme dat gebaseerd is op de paginafoutfre- 
quentie. | 
Belady [1966], Fine et al. [1966], Coffman en Varian [1968], Freibergs 
[1968], Brawn en Gustavson [1968], Hatfield [1972] en Baer en Sager [1972] deden 
experimenten om het dynamisch gedrag van programma’s onder paginering te 
bestuderen. Denning [1968], Oppenheimer en Weizer [1968], DeMeis en Weizer 
[1969] en Alderson et al. [1972] beschouwden diverse strategieën voor het onder 
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controle houden van de werkbelasting om stampen te voorkomen. 

Wolman [1965], Randell [1969], Arden en Boettner [1969], Batson et al. 
[1970], Denning [1970] en Hatfield en Gerald [1971] bespraken pagina- en seg- 
mentgrootten. 

Vareha et al. [1969], Kuck en Lawrie [1970] en Mattson et al. [1970] bespra- 
ken interne geheugens met meerdere niveaus. Zulke methoden werden in verschil- 
lende grote machines geimplementeerd, waaronder de IBM 370/168 en de IBM 
370/195 [Liptay 1968). 

Randell en Keuhner [1968], Denning [1970], Doran [1970] en Hoare en 
McKeag [1972] gaven overzichtsartikelen over paginering. Besprekingen op het 
niveau van een elementair leerboek worden gegeven door Watson [1970], paragra- 
fen 2.4 en 2.5], Madnick en Donovan [1974, hoofdstuk 3], Tsichritzis en Bernstein 
[1974, hoofdstuk 5], Shaw [1974, hoofdstuk 5], Lister [1975, hoofdstuk 5], Haber- 
mann [1976, hoofdstukken 7 en 8] en Calingaert [1982, hoofdstuk 2]. 


{T 


WERKINDELING SCHIJF- EN 
TROMMELGEHEUGEN 


In de laatste paar hoofdstukken hebben we gezien hoe de centrale verwerkings- 
eenheid en het geheugen van een computer aan gebruikers kunnen worden toe- 
gewezen. De dynamische toekenning van deze systeemfaciliteiten stelt het com- 
putersysteem in staat efficiënter te werken. In dit hoofdstuk bezien we een ander 
zeer belangrijk werkindelingsprogramma, de schijf-werkindeler, en enkele van de 
verschillende algoritmen die gebruikt worden voor het toegang verkrijgen tot de 
schijf. 

_ Het merendeel van de verwerking door moderne computersystemen con- 
centreert zich op het schijvensysteem. Schijven zorgen voor de primaire gekoppel- 
de opslag van informatie, programma’s zowel als gegevens. De meeste program- 
ma's, zoals compileerprogramma’s, assembleerprogramma’s, sorteerroutines, 
tekstverwerkings- en tekstopmaakprogramma’s, enzovoort, worden op een schijf 
opgeslagen totdat ze in het geheugen worden geladen en dan gebruiken ze de 
schijf als de bron en tevens als de bestemming van hun verwerking. Daarom is 
het juiste beheer van schijfopslagruimte voor een computersysteem van centraal 
belang. 

Er is weinig andere keus. Magneetbandsystemen zijn in het algemeen te 
langzaam. Bovendien beperken ze zich tot sequentiële toegang. Zo zijn magneet- 
banden geschikter voor het opslaan van bestanden die niet dikwijls gebruikt wor- 
den, waarbij snelheid geen belangrijke rol speelt. 


7.1 Fysieke kenmerken 


In fysiek opzicht zijn schijven betrekkelijk eenvoudig (zie figuur 7.1). Elke schijf 
heeft een platte, cirkelvormige vorm, zoals een grammofoonplaat. De twee opper- 
vlakken zijn bedekt met een magnetisch materiaal, zoals ook bij een magneet- 
band. De informatie wordt op de twee oppervlakken vastgelegd. 

Wanneer de schijf in gebruik is, wordt deze door een motor met hoge snel- 
heid rondgedraaid (bijvoorbeeld 3600 omwentelingen per minuut). Er is een lees/ 
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| lees/schrijf- 
koppen 


draairichting 


Figuur 7.1 
Mechanisme van een schijf met bewegende magneetkoppen 


schrijfkop vlak boven het oppervlak van de schijf gepositioneerd. Het schijfop- 
pervlak is logisch in sporen verdeeld. De informatie wordt opgeslagen door deze 
magnetisch op het spoor onder de lees/schrijfkop vast te leggen. Er kunnen wel 
honderden sporen op een schijfoppervlak zijn. 

Een schijf met vaste lees/schrijfkoppen heeft voor elk spoor een afzonderlijke 
magneetkop. Deze opzet geeft de computer de mogelijkheid snel van het ene 
spoor op het andere over te gaan, maar vereist een groot aantal magneetkoppen, 
en dit maakt het randapparaat erg duur. Het komt vaker voor dat er slechts één 
magneetkop is die heen en weer beweegt om de toegang tot verschillende sporen 
te bewerkstelligen. Deze schijf met bewegende lees! schrijfkoppen vereist appara- 
tuur voor het bewegen van de kop, maar er is slechts één enkele kop nodig, waar- 
door het systeem veel goedkoper is. 

Logisch gezien is een schijf met vaste lees/schrijfkoppen hetzelfde als een 
trommel. Een trommel heeft de vorm van een cilinder in plaats van een schijf en 
het vastleggen wordt op de zijkant gedaan in plaats van op de onder- en boven- 
kant. Hoewel het mogelijk zou zijn een trommel met bewegende lees/schrijfkop- 
pen te maken, hebben in feite alle trommels een vaste magneetkop. Gewoonlijk 
hebben trommels een grotere overbrengsnelheid dan schijven, maar een kleinere 
opslagcapaciteit. Trommels zijn in het algemeen erg duur, maar het gebruik ervan 
kan geschikt zijn voor situaties die een hoog prestatievermogen vereisen. 

Trommels werden gewoonlijk gebruikt als het hulpgeheugen voor pagine- 
ringssystemen uit de beginperiode. Het hulpgeheugen werd dan de program- 
maverwisselingstrommel of de pagineertrommel genoemd. Veel systemen maken 
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nu gebruik van een snelle schijf of, en dat is de jongste ontwikkeling, van een 
groot halfgeleider- of kernengeheugen dat als een trommel werkt maar nog hoge- 
re toegangs- en overbrengsnelheden heeft. 

Oorspronkelijk werden schijven ontworpen voor de opslag van bestanden; 
dus de hoofdcriteria bij hun ontwerp waren de prijs, de omvang en de snelheid. 
Om extra opslagcapaciteit te krijgen bediende men zich van diverse methoden. 
De belangrijkste winst werd geboekt door het verbeteren van de opslagdichtheid, 
waardoor meer bits op een oppervlak konden worden gezet. De dichtheid komt 
tot uiting in het aantal sporen per inch, en dus in het totale aantal sporen op een 
oppervlak. Bovendien kan met afzonderlijke magneetkoppen aan elke kant van 
de plaat de capaciteit van de schijf tegen geringe kosten worden verdubbeld. Deze 
methode kan worden uitgebreid door aan één as bevestigd verschillende schijven 
op elkaar te stapelen, elk met twee oppervlakken voor het vastleggen van infor- 
matie. Omdat deze alle samen ronddraaien is slechts één aandrijfmotor nodig, 
hoewel elk oppervlak nog steeds zijn eigen lees/schrijfkop nodig heeft. 

Tenslotte kan de schijf verwisselbaar zijn, waardoor verschillende schijven, 
al naar dat nodig is, kunnen worden opgezet. Verwisselbare schijvenpakketten 
kunnen uit één of meer schijven bestaan. In het algemeen worden deze in harde 
plastic dozen bewaard om te voorkomen dat ze worden beschadigd als ze niet in 
de schijfaandrijfeenheid staan. 

Zulke grote schijven zijn onbuigzame aluminium platen die bedekt zijn met 
magnetisch materiaal voor het vastleggen van informatie. De lees/schrijfkoppen 
worden zo dicht mogelijk bij het schijfoppervlak gehouden. Vaak drijft of vliegt 
de magneetkop, ondersteund door een luchtkussen, slechts enkele microns boven 
het schijfoppervlak. Omdat de magneetkop zo dicht bij het oppervlak drijft, moe- 
ten de platen met zorg worden gefabriceerd zodat ze heel vlak zijn. 

Beschadigingen door de magneetkop kunnen een probleem vormen. Als 
de magneetkop met het oppervlak in contact komt (wegens een stroomstoring 
bijvoorbeeld), schraapt de magneetkop het materiaal dat voor het vastleggen van 
informatie gebruikt wordt van de schijf af, waardoor de gegevens op die plaats 
vernietigd worden. | 

Een andere methode wordt gevormd door diskettes (floppy disks, of ’flop- 
pies’). Deze schijven zijn bedekt met een laagje van een harde stof, zodat de lees/ 
schrijfkop in direct contact met het oppervlak kan zijn zonder dat de gegevens 
worden vernietigd. Op deze manier kan de schijf zelf veel goedkoper gefabriceerd 
en gebruikt worden. Het laagje (en de lees/schrijfkop) zullen echter na langdurig 
gebruik slijten en moeten dan mettertijd worden vervangen. 

Diskettes zijn gewoonlijk veel kleiner dan harde schijven, uiteenlopend van 
100K tot 500K bytes per schijf. Ze komen uit in allerlei variaties (enkelzijdig, 
dubbelzijdig, met enkele dichtheid en dubbele dichtheid) en maten (8 inch, 
5% inch, enzovoort). Harde schijven variëren van 5 megabytes tot meer dan 300 
megabytes per aandrijfeenheid. Harde schijven zijn ook sneller en duurder. 

De apparatuur voor een schijvensysteem kan in twee delen worden ver- 
deeld. De schijfaandrijfeenheid is het mechanische gedeelte, met inbegrip van de 
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motor van het apparaat, de lees/schrijfkoppen, en de bijbehorende electronica. 
Het andere gedeelte, dat de schijvenbesturingseenheid wordt genoemd, bepaalt de 
logische interactie met de computer. De besturingseenheid neemt instructies van 
de CVE aan en geeft aan de schijfaandrijfeenheid de opdracht de instructie uit 
te voeren. Deze onderverdeling zorgt ervoor dat veel schijfaandrijfeenheden aan 
dezelfde schijvenbesturingseenheid kunnen worden gekoppeld. Als een systeem 
in eerste instantie één schijvenbesturingseenheid en één schijfaandrijfmechanis- 
me heeft, kan de schijfopslagcapaciteit van het systeem voor minder dan twee- 
maal de prijs worden verdubbeld, eenvoudig door een tweede schijfaandrijfeen- 
heid aan dezelfde schijvenbesturingseenheid te koppelen. 

Naar informatie op de schijf wordt verwezen met behulp van een adres dat 
uit verschillende delen bestaat, zoals het nummer van de aandrijfeenheid, het 
oppervlak en het spoor. Alle sporen op een aandrijfeenheid (eigenlijk de sporen 
op de verschillende oppervlakken) waartoe toegang kan worden verkregen zonder 
de magneetkoppen te bewegen, noemt men een cilinder. 

Binnen een spoor wordt de informatie als blokken geschreven. De blokken 
kunnen een vaste grootte hebben die is vastgelegd door de apparatuur. Deze 
worden dan sectoren genoemd. Elke sector kan afzonderlijk worden gelezen of 
geschreven. Het is ook mogelijk dat de informatie op een spoor is samengesteld 
uit blokken van variabele lengte, die van elkaar gescheiden zijn door record- 
tussenruimten. Dit schema is flexibeler, maar moeilijker om mee te werken. Veel 
systemen zullen, zelfs met door de apparatuur bepaalde schijfblokken van varia- 
bele lengte, een blokgrootte uitkiezen en deze vastleggen in de programmatuur. 
In beide gevallen wordt informatie als blokken gelezen en weggeschreven. Het 
blokken en ontblokken van records in de programmatuur kan gemakkelijk de 
vaste of variabele aard van de fysieke blokgrootte aan het oog onttrekken. 

De schijfsnelheid is uit drie delen samengesteld. Om tot een blok op de 
schijf toegang te krijgen moet het systeem eerst de magneetkop naar de juiste 
cilinder bewegen. Deze beweging van de magneetkop noemt men een zoekbewer- 
king, en de tijd die nodig is om deze te doen heet de zoektijd. Staat de magneetkop 
eenmaal boven het juiste spoor, dan moet deze wachten tot het gewenste blok 
onder de lees/schrijfkop draait. Deze vertraging is de schijfwachttijd (Engels: 
latency time). Ten slotte kan de feitelijke overbrenging van gegevens tussen de 
schijf en het hoofdgeheugen plaatsvinden. Dit laatste deel is de overbrengtijd. De 
totale tijd die nodig is voor het afhandelen van een verzoek voor een schijfbewer- 
king is de som van de zoektijd, de schijfwachttijd en de overbrengtijd. 

Aangezien de meeste jobs voor het laadproces en voor de invoer- en uitvoer- 
bestanden erg van de schijf afhankelijk zijn, is het belangrijk dat schijfbewerkin- 
gen zo snel mogelijk plaatsvinden. Het besturingssysteem kan de gemiddelde tijd 
die daarvoor nodig is verbeteren door voor de verzoeken om toegang tot schijven 
van werkindeling gebruik te maken. 

Zoals we in hoofdstuk 2 bespraken, heeft elk randapparaat, en dus ook elke 
schijfaandrijfeenheid, een wachtrij van uitstaande verzoeken. Telkens wanneer 
een proces I/O naar of van de schijf nodig heeft, voert het een systeemaanroep 
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bestemd voor het besturingssysteem uit. Het verzoek specificeert de verschillende 
stukjes noodzakelijke informatie: | 


@ Is dit een invoer- of een uitvoerbewerking? 

@ Het schijfadres (aandrijfeenheid, cilinder, oppervlak, blok). 

@ Het geheugenadres. 

@ De hoeveelheid informatie die moet worden overgebracht (een aantal bytes of 
woorden). 


Als de gewenste schijfaandrijfeenheid en schijvenbesturingseenheid be- 
schikbaar zijn, kan het verzoek onmiddellijk behandeld worden. Echter, als de 
aandrijfeenheid of de besturingseenheid bezig is met het behandelen van een ver- 
zoek, moeten verdere verzoeken, gewoonlijk van andere processen, in de wachtrij 
geplaatst worden. 

Voor een systeem met multiprogrammering en veel processen kan de wacht- 
rij voor de schijf dikwijls niet-leeg zijn. Dus moeten we, wanneer een verzoek 
is uitgevoerd, een nieuw verzoek uit de wachtrij kiezen en dit behandelen. Een 
schijfbewerking vereist dat de magneetkop naar het gewenste spoor wordt be- 
wogen, dan volgt de schijfwachttijd en uiteindelijk de overbrenging van de gege- 
vens. 


7.2 Wie-het-Eerst-Komt-het-Eerst-Maalt 


De eenvoudigste vorm van schijf-werkindeling is natuurlijk Wie-het-Eerst-Komt- 
het-Eerst-Maalt’ (WEKEM). Dit algoritme is gemakkelijk te programmeren en 
naar zijn aard eerlijk. Het kan echter zijn dat het niet de beste (gemiddelde) 
bedieningstijd oplevert. Neem bijvoorbeeld een geordende schijf-wachtrij met 
verzoeken waarbij de volgende sporen betrokken zijn: 


98, 183, 37, 122, 14, 124, 65 en 67, 


in de volgorde van het eerste (98) tot het laatste (67). Als de lees/ schrijfkop zich 
aanvankelijk boven spoor 53 bevindt, zal deze eerst van 53 naar 98 bewegen, dan 
naar 183, 37, 122, 14, 124, 65 en tenslotte naar 67, waarbij de totale beweging 
van de magneetkop zich uitstrekt over 640 sporen. Deze werkindeling is als een 
diagram weergegeven in figuur 7.2. 

Het probleem met deze werkindeling wordt geïllustreerd door de wilde 
zwaai van 122 naar 14, en dan terug naar 124. Als de verzoeken voor de sporen 
37 en 14 samen bediend konden worden, voor of na de verzoeken voor sporen 
122 en 124, zou de beweging van de magneetkop aanzienlijk kunnen worden 
verminderd en zou de gemiddelde afhandelingstijd voor elk verzoek omlaaggaan, 
waardoor de doorvoercapaciteit van de schijf beter wordt. 
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Wachtrij = 98, 183, 37, 122, 14, 124, 65, 67 
Magneetkop begint bij 53 


14 37 53 6567 98 122124 183 


il 


Figuur 7.2 
Schijf-werkindeling volgens 'Wie-het-Eerst-Komt-het-Eerst-Maalt' (WEKEM) 


7.3 Kortste-Zoektijd-Eerst 


Het lijkt redelijk alle verzoeken voor sporen die dichtbij de momentele positie 
van de magneetkop liggen gezamenlijk af te handelen, voordat de magneetkop 
ver wordt wegbewogen voor het afhandelen van een ander verzoek. Deze veron- 
derstelling vormt de basis voor het ’Kortste-Zoektijd-Eerst’-algoritme (KZE) voor 
schijf-werkindeling. KZE selecteert het verzoek met de kleinste zoektijd uitgaan- 
de van de huidige positie van de magneetkop. Aangezien de zoektijd in het alge- 
meen evenredig is met het verschil in sporen tussen de verzoeken, wordt deze 
benadering geïmplementeerd door dat verzoek in de wachtrij te selecteren waar- 
voor het spoor het dichtst bij het huidige spoor ligt. 

In het voorbeeld van onze wachtrij is het verzochte spoor dat het dichtst 
bij het huidige spoor (53) ligt spoor 65. Als we eenmaal op spoor 65 zijn, is het 
volgende dichtst bij gelegen spoor: spoor 67. Op dit punt is de afstand tot spoor 
37 gelijk aan 30, terwijl de afstand tot spoor 98 nu 31 bedraagt. Spoor 37 ligt 
dichterbij en daarom wordt dit verzoek vervolgens geselecteerd. Zo doorgaande 
behandelen we het verzoek voor spoor 14, dan 98, 122, 124 en tenslotte 183 (zie 
figuur 7.3). Deze methode van werkindeling heeft een totale beweging van de 
magneetkop over slechts 236 sporen tot gevolg, iets meer dan eenderde van de 
afstand die nodig is voor WEKEM. Dit algoritme zou een aanzienlijke verbete- 
ring in gemiddelde schijfbedieningstijd tot gevolg hebben. 

KZE is in wezen een vorm van KJE-werkindeling (Kortste-Job-Eerst) en, 
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Wachtrij = 98, 183, 37, 122, 14, 124, 65, 67 
Magneetkop begint bij 53 


14 37 53 6567 98 122124 183 


Figuur 7.3 
Schijf-werkindeling volgens 'Kortste-Zoektijd-Eerst’ (KZE) 


evenals dat met KJE het geval is, kan dit voor sommige verzoeken verhongering 
veroorzaken. Denk eraan dat in een echt systeem op elk moment verzoeken kun- 
nen arriveren. Stel dat we twee verzoeken in de wachtrij hebben, voor spoor 14 
en spoor 186. Als een verzoek binnenkomt voor een spoor dichtbij 14, terwijl we 
bezig zijn dit te behandelen, zal dat als het volgende verzoek worden behandeld, 
waardoor het verzoek voor spoor 186 moet wachten. Terwijl dit verzoek wordt 
behandeld, zou een ander verzoek voor een spoor dichtbij 14 kunnen aankomen. 
Theoretisch zou er een continue stroom van verzoeken voor dichtbij elkaar ge- 
legen sporen kunnen aankomen, waardoor het verzoek voor spoor 186 voor on- 
bepaalde tijd zou moeten wachten. 

Het KZE-algoritme is, hoewel het een aanzienlijke verbetering ten aanzien 
van WEKEM betekent, niet optimaal. Als we bijvoorbeeld de magneetkop van 
spoor 53 naar spoor 37 bewegen, hoewel dit niet het dichtst bij gelegen spoor is, 
en dan naar spoor 14, voordat we omkeren om de verzoeken voor sporen 65, 67, 
98, 122, 124 en 183 te behandelen, kunnen we de totale beweging van de magneet- 
kop tot 208 sporen terugbrengen. 


14 AFTAST 


Erkenning van de dynamische aard van de verzoek-wachtrij leidt tot het 
AFTAST-algoritme. De lees/schrijfkop begint bij het ene eind van de schijf en 
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beweegt naar het andere eind, waarbij hij bij elk spoor dat hij tegenkomt de 
bijbehorende verzoeken afhandelt, totdat hij bij het andere einde van de schijf 
aankomt. Aan het andere eind wordt de richting van de beweging van de mag- 
neetkop omgekeerd en gaat het afhandelen van verzoeken verder. De magneetkop 
tast voortdurend de schijf van het ene einde tot het andere einde af. 

Voordat we ’'AFTAST’ toepassen op ons voorbeeld, 


98, 183, 37, 122, 14, 124, 65 en 67, 


moeten we, behalve de laatste positie, ook de richting van de beweging van de 
magneetkop weten. Als de magneetkop in de richting van spoor 0 bewoog, zou 
hij bij deze beweging de verzoeken voor de sporen 37 en 14 afhandelen. Op spoor 
O aangekomen zou de magneetkop omkeren en naar het andere einde van de 
schijf bewegen, waarbij de verzoeken voor sporen 65, 67, 98, 122, 124 en 183 
tijdens deze beweging worden afgehandeld (zie figuur 7.4). Als in de wachtrij een 
verzoek aankomt voor een spoor dat juist vóór de magneetkop ligt, zal het bijna 
onmiddellijk behandeld worden, terwijl een verzoek dat juist achter de magneet- 
kop komt zal moeten wachten tot de magneetkop naar het einde van de schijf is 
bewogen, van richting is omgekeerd en is teruggekeerd, voordat het behandeld 
wordt. 

Het AFTAST-algoritme wordt soms het ’lift’-algoritme genoemd, omdat 
het zich gedraagt als een lift die in een gebouw verzoeken om van de ene verdie- 


Wachtrij = 98, 183, 37, 122, 14, 124, 65, 67 
Magneetkop begint bij 53 


14 37 53 6567 98 122124 183 


ia A 


Figuur 7.4 
Schijf-werkindeling volgens 'AFTAST’ 
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ping naar de andere te gaan afhandelt. Een andere analogie is het sneeuwvrij 
maken van een trottoir terwijl het aan het sneeuwen is. Beginnend aan het ene 
einde bewegen we al sneeuwschuivend naar het andere einde. Bij het voortbewe- 
gen valt nieuwe sneeuw achter ons. Aan het andere einde keren we om en verwij- 
deren we de sneeuw die zojuist achter ons gevallen is. 

Als we uitgaan van een uniforme verdeling van verzoeken voor sporen, kijk 
dan eens naar de dichtheid van de verzoek-sporen wanneer de magneetkop het 
ene eind heeft bereikt en van richting verandert. Op dit punt zijn er betrekkelijk 
weinig verzoeken voor sporen onmiddellijk achter de magneetkop, daar deze ver- 
zoeken pas nog behandeld zijn. De grootste dichtheid van verzoek-sporen is aan 
het andere eind van de schijf. De verzoeken voor deze sporen hebben het langst 
moeten wachten. 

C-AFTAST (Cirkelvormige AFTAST) is een variant van AFTAST die ont- 
worpen is om te zorgen voor een uniformere bedieningswachttijd. Evenals dat 
met AFTAST het geval is, beweegt C-AFTAST de magneetkop van het ene naar 
het andere eind van de schijf, onderweg verzoeken afhandelend. Echter, bij het 
bereiken van het andere uiteinde keert de magneetkop onmiddellijk terug naar 
het begin van de schijf, zonder ook maar één verzoek op de terugtocht af te 
handelen. C-AFTAST behandelt de schijf in wezen alsof deze cirkelvormig was, 
waarbij het laatste spoor aan het eerste grenst (zie figuur 7.5). 

Merk op dat in onze beschrijvingen van zowel AFTAST als C-AFTAST de 
magneetkop altijd van het ene naar het andere eind beweegt. In de praktijk is 


Wachtrij = 98, 183, 37, 122, 14, 124, 65, 67 
Magneetkop begint bij 53 
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Figuur 7.5 
Schijf-werkindeling volgens 'C-KIJK’ 
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geen van beide algoritmen op deze manier geïmplementeerd. Het is gebruikelijker 
dat de magneetkop niet verder dan het laatste verzoek-spoor in elk van beide 
richtingen wordt bewogen. Zodra er geen verzoek-sporen zijn in de huidige rich- 
ting, wordt de beweging van de magneetkop omgekeerd. Deze versies van AF- 
TAST en C-AFTAST worden KIJK en C-KIJK genoemd. (Kijk uit naar een 
verzoek-spoor alvorens in die richting te bewegen’) 


7.5 Keuze van een algoritme voor schijf-werkindeling 


Hoe kiezen we nu, waar we zoveel algoritmen voor schijf-werkindeling hebben, 
een bepaald algoritme? KZE is heel gebruikelijk en heeft een natuurlijke aantrek- 
kingskracht. AFTAST en C-AFTAST zijn meer geschikt voor systemen met een 
zware werkbelasting op de schijf. Het is mogelijk een optimaal algoritme te de- 
finiëren, maar de berekening die nodig is voor een optimale werkindeling zou de 
winst op KZE en AFTAST wel eens teniet kunnen doen. Teorey en Pinkerton 
[1972] vergeleken de verschillende algoritmen door gebruik te maken van simula- 
tie en bevalen het gebruik aan van óf AFTAST óf C-AFTAST, afhankelijk van 
de werkbelasting. | 

Bij elk algoritme voor werkindeling hangt echter het prestatievermogen af 
van het aantal en het soort verzoeken. Vooral als er zelden meer dan één uitstaand 
verzoek in de wachtrij staat zijn alle algoritmen voor werkindeling gelijkwaardig. 
Sommige studies hebben aanwijzingen gegeven [Lynch 1972b] dat de wachtrij 
gewoonlijk slechts één verzoek bevat. In dit geval is WEKEM ook een goed algo- 
ritme. 

Merk ook op dat de verzoeken om schijf-dienstverlening sterk kunnen wor- 
den beïnvloed door de methode die gebruikt wordt voor het toewijzen van be- 
standsruimte. Een programma dat een bestand met aaneengesloten toewijzing 
aan het lezen is, zal een aantal verzoeken produceren voor sporen die dicht bijeen 
op de schijf liggen, waarbij de magneetkop slechts weinig hoeft te bewegen. Bij 
een aaneengeschakeld of geïndiceerd bestand daarentegen kunnen blokken be- 
trokken zijn die overal verspreid op de schijf liggen, wat tot gevolg heeft dat tegen 
de prijs van beweging van de magneetkop de schijfruimte beter wordt benut. 

De plaats van adresboeken en indexblokken is ook belangrijk. Daar elk 
bestand om te kunnen worden gebruikt geopend moet worden, en het openen 
van een bestand het doorzoeken van de adresboekstructuur vereist, zal tot de 
adresboeken dikwijls toegang moeten worden gekregen. Het plaatsen van de 
adresboeken in het midden van de schijf in plaats van aan één van beide uiteinden 
kan de beweging van de magneetkop aanzienlijk verminderen. 

Als gevolg van deze beschouwingen moet het duidelijk zijn dat het algorit- 
me voor schijf-werkindeling, evenals alle andere algoritmen, als een aparte mo- 
dule van het besturingssysteem geschreven moet worden; we kunnen het dan, 
indien nodig, verwijderen en door een ander algoritme vervangen. Om te begin- 
nen zouden WEKEM of KZE redelijke keuzen zijn. 
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7.6 Sector-wachtrijvorming 


De algoritmen voor schijf-werkindeling die we zojuist besproken hebben 
(WEKEM, KZE, AFTAST en C-AFTAST) hebben alle ten doel de beweging 
van de magneetkop zo klein mogelijk te maken, om de totale bedieningstijd en 
wachttijd zo klein mogelijk te doen zijn. Randapparaten met vaste magneetkop- 
pen, zoals trommels, hebben dit probleem echter niet, omdat er geen beweging 
van de magneetkop is en er geen merkbare tijd nodig is voor het selecteren van 
een spoor. Dus worden voor deze apparaten andere algoritmen gebruikt. 

Sector-wachtrijvorming is een algoritme voor de werkindeling van apparaten 
met niet-bewegende magneetkoppen. Het is gebaseerd op de verdeling van elk 
spoor in een vast aantal blokken, die sectoren worden genoemd. Het schijfadres 
in ieder verzoek vermeldt het spoor en de sector. Omdat de zoektijd voor appara- 
ten met niet-bewegende magneetkoppen nul is, is het belangrijkste deel van de 
bedieningstijd de schijfwachttijd. Voor WEKEM-werkindeling is de verwachte 
schijfwachttijd een halve omwenteling, aangenomen dat verzoek-sectoren uni- 
form over alle sectoren verdeeld zijn. 

Kijk evenwel eens naar het volgende voorbeeld. Stel dat de magneetkop 
zich op het moment boven sector 2 bevindt en het eerste verzoek in de wachtrij 
betrekking heeft op sector 12. Om dit verzoek af te handelen moeten we wachten 
tot sector 12 onder de lees/schrijfkoppen doordraait. Als er een verzoek in de 
wachtrij is voor sector 5, zou dit vóór het verzoek voor sector 12 behandeld kun- 
nen worden, zonder dat het verzoek voor sector 12 daardoor vertraagd wordt. Zo 
kunnen we onze doorvoercapaciteit sterk verbeteren door voor elke sector een 
verzoek af te handelen wanneer deze onder de magneetkop doorkomt, zelfs als 
het verzoek niet vooraan in de wachtrij staat. 

Sector-wachtrijvorming houdt in dat voor elke sector van de trommel een 
afzonderlijke wachtrij gedefinieerd wordt. Wanneer er een verzoek arriveert voor 
sector i, wordt dit in de wachtrij voor sector i geplaatst (zie figuur 7.6). Wanneer 
sector i onder de lees/schrijfkoppen doordraait, wordt het eerste verzoek in de 
wachtrij voor sector i behandeld. 

Sector-wachtrijvorming wordt in de eerste plaats bij randapparaten met 
niet-bewegende magneetkoppen gebruikt. Het kan echter ook voor randappara- 
ten met bewegende magneetkoppen worden gebruikt, als er meer dan één verzoek 
voor dienstverlening binnen een bepaald spoor of een bepaalde cilinder is. Wan- 
neer de magneetkop eenmaal naar een bepaalde cilinder bewogen is, kunnen alle 
verzoeken voor deze cilinder afgehandeld worden zonder verdere beweging van 
de magneetkop. Daarom kan sector-wachtrijvorming worden gebruikt voor het 
ordenen van meerdere verzoeken voor adressen binnen dezelfde cilinder. Natuur- 
lijk kan, en dit geldt eveneens voor andere algoritmen voor werkindeling, sector- 
wachtrijvorming alleen effect sorteren als het besturingssysteem moet kiezen uit 
een groep van meerdere verzoeken. 
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Figuur 7.6 
Sector-wachtrijvorming 


7.7 Samenvatting 


Schijvensystemen vormen op de meeste computers het belangrijkste medium voor 
de I/O. Verzoeken voor schijf-I/O worden zowel door het bestandssysteem als 
door virtuele-geheugensystemen gegenereerd. Elk verzoek vermeldt het adres op 
de schijf waarnaar verwezen moet worden. Dit adres bevat onder andere een 
spoor- of cilindernummer. Schijf-algoritmen voor werkindeling voor randappara- 
tuur met bewegende magneetkoppen trachten de totale beweging van de mag- 
neetkop minimaal te maken. WEKEM, KZE, AFTAST en C-AFTAST zijn ver- 
schillende algoritmen voor schijf-werkindeling. Sector-wachtrijvorming is een al- 
goritme voor werkindeling voor randapparatuur met niet-bewegende magneet- 
koppen, zoals trommels. 
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Opgaven 


7.1 Stel dat de kop van een schijf met bewegende magneetkop en 200 sporen, 
genummerd 0 tot en met 199, op het moment een verzoek afhandelt voor 
spoor 143 en juist een verzoek heeft afgehandeld op spoor 125. Als de 
verzoek-wachtrij in FIFO-volgorde wordt bijgehouden: 


86, 147, 91, 177, 94, 150, 102, 175, 130, 


wat is dan de totale beweging van de magneetkop voor het afhandelen 
van deze verzoeken voor de volgende algoritmen voor schijf-werkinde- 
ling? 

a. WEKEM. 

b. KZE. 

c. AFTAST. 

d. KIJK. 

e. C-AFTAST. 


7.2 Fragmentatie op een opslagapparaat zou geëlimineerd kunnen worden 
door de informatie opnieuw te comprimeren. Normale schijven en trom- 
mels hebben geen verplaatsings- of basisregisters (zoals die welke ge- 
bruikt worden wanneer geheugen moet worden gecomprimeerd). Hoe 
kunnen we dan bestanden verplaatsen? Waarom vermijdt men vaak het 
opnieuw comprimeren en verplaatsen van bestanden? 


7.3 Waarom zou men liever een trommel dan een schijf als pagineerapparaat 
gebruiken? 


7.4 Wanneer de gemiddelde wachtrijlengte klein is, degeneren alle algorit- 
men voor schijf-werkindeling tot WEKEM-werkindeling. Leg uit waar- 
om. 


7.5 Wat is het belangrijkste verschil tussen het idee schijf-werkindeling en 
het idee ’lift-werkindeling’? (Aanwijzing: proberen we de beweging van 
een lift minimaal te maken?) 


7.6 Geen enkel algoritme voor schijf-werkindeling, afgezien van WEKEM, 
is echt eerlijk (er kan verhongering plaatsvinden). 
a. Leg uit waarom. 
b. Bedenk een methode die eerlijkheid garandeert. 
c. Waarom is eerlijkheid een belangrijk doel in een systeem met tijd- 
deling? 


7.7 Vergelijk de doorvoercapaciteit van C-AFTAST en AFTAST, als we uit- 
gaan van een uniforme verdeling van de verzoeken. 


7.8 KZE heeft de neiging cilinders in het middengebied van de schijf te be- 
voordelen boven de binnenste en buitenste cilinders. Verklaar waarom. 
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7.9 Verzoeken zijn gewoonlijk niet uniform verdeeld. Bijvoorbeeld, de cilin- 
ders waarop de adresboekstructuur staat worden vaker benaderd dan de 
cilinders waarop de meeste bestanden staan. Stel dat u weet dat 50% van 
de verzoeken betrekking heeft op een klein aantal cilinders. 

a. Welk algoritme voor werkindeling zou u gebruiken? 
b. Kunt u met het oog op dit geval een nieuw algoritme voor werkinde- 
ling bedenken? 


7.10 Waarom wordt in schijf-werkindeling gewoonlijk geen gebruik gemaakt 
van het optimaliseren van de schijfwachttijd? Hoe zouden de standaard- 
algoritmen (WEKEM, KZE, AFTAST en C-AFTAST) zo gewijzigd 
kunnen worden dat optimalisering van de schijfwachttijd er ook in be- 
grepen is? 


7.11 Is andere dan WEKEM-schijf-werkindeling nuttig in een omgeving met 
één gebruiker? 


7.12 Door de prijsdaling van halfgeleidergeheugens zijn enkele firma’s begon- 
nen halfgeleider’schijven’ te fabriceren. Deze apparaten gebruiken ge- 
heugenchips in plaats van schijven voor opslagruimte. Als gevolg daar- 
van hebben deze schijven geen bewegende delen en daarom zijn ze snel- 
ler en betrouwbaarder dan de normale mechanische schijven. Deze nieu- 
we apparaten zijn ervoor ontworpen om volledig uitwisselbaar (Engels: 
plug-compatible) te zijn met bestaande schijven, zodat programmering en 
adressering identiek zijn met die voor normale schijven. Zij zijn evenwel 
veel sneller. Welk effect zou dit hebben op de keuze van een algoritme 
voor schijf-werkindeling? 


7.13 Terwijl hij op zoek is naar een baan, hoort een student een werkgever 
zeggen dat hun systeem sector-wachtrijvorming gebruikt om de be- 
weging van de magneetkop op hun schijven met bewegende magneetkop- 
pen zo klein mogelijk te maken. Wat denkt u van deze bewering? 


Bibliografische verwijzingen 


_ Denning [1967] beschreef de WEKEM-, KZE- en AFTAST-algoritmen voor 
schijf-werkindeling. Een volledig overzicht van al de verschillende algoritmen 
voor schijf-werkindeling is gegeven door Teorey [1972] en Teorey en Pinkerton 
[1972]. 

Wilhelm [1976] en Hofri [1980] vergeleken de WEKEM- en KZE-algorit- 
men voor de indeling van zoekbewerkingen. Frank [1969], Gotlieb [1973], Fuller 
[1974], en Perros [1980] berekenden diverse aspecten van het prestatievermogen 
van algoritmen voor schijf-werkindeling. 

Lynch [1972b] en Wilhelm [1976] bespraken de gevolgen van niet-uniforme 
verdelingen van verzoeken. 
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Denning [1967] gaf diverse algoritmen voor trommel-werkindeling, waar- 
onder WEKEM en KTE (Kortste-Toegangstijd-Eerst). Analyses van een pa- 
gineertrommel kunnen worden gevonden in de artikelen van Weingarten [1966], 
Coffman [1969] en Fuller [1972]. Abate en Dubner [1969], Stone [1973] en Fuller 
[1974] bespraken omwentelingsoptimalisering voor apparaten met niet-bewegen- 
de magneetkoppen, zoals trommels. 


IMPASSES 


In een omgeving met multiprogrammering kunnen verschillende processen wed- 
ijveren om een eindig aantal systeemelementen. Een proces vraagt systeemele- 
menten aan en gaat, als de systeemelementen op dat moment niet beschikbaar 
zijn, een wachttoestand in. Het kan gebeuren dat de processen die staan te wach- 
ten nooit meer uit die toestand komen, omdat de systeemelementen waarom ze 
hebben verzocht door andere wachtende processen bezet worden gehouden. Deze 
situatie treedt bijvoorbeeld op in een systeem met vier magneetbandeenheden en 
twee processen. Als elk process twee magneetbandeenheden bezet houdt maar er 
drie nodig heeft, zal elk proces erop wachten dat het andere proces zijn magneet- 
bandeenheden vrijgeeft. Deze situatie wordt een impasse genoemd. Om een im- 
passe te voorkómen, of er weer uit te komen als er een impasse optreedt, kan het 
systeem een of andere betrekkelijk extreme actie ondernemen, zoals het voortijdig 
ontnemen van systeemelementen aan één of meer processen die in een impasse 
geraakt zijn. In dit hoofdstuk beschrijven we enkele van de verschillende me- 
thoden die besturingssystemen kunnen gebruiken om het impasseprobleem te 
behandelen. 


8.1 Het impasseprobleem 


Het probleem van impasses is niet uniek voor de omgeving van een besturingssys- 
teem. Bij het generaliseren van onze interpretatie van systeemelementen en 
processen kunnen we zien, dat het impasseprobleem deel van onze dagelijkse 
omgeving kan uitmaken. Neem bijvoorbeeld het probleem van het oversteken 
van een rivier via een aantal stenen die daarin liggen (zie figuur 8.1). Er kan 
slechts één voet tegelijk op iedere steen staan. Om de rivier over te steken moet 
een persoon elk van de stenen gebruiken. We kunnen iedere persoon die de rivier 
oversteekt zien als een proces, en elke steen als een systeemelement. Er treedt 
een impasse op wanneer twee personen van de tegenovergestelde kant de rivier 
beginnen over te steken en elkaar in het midden ontmoeten (zie figuur 8.2). 
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Figuur 8.1 


Het oversteken van een rivier 


Het op een steen stappen kan men opvatten als het verkrijgen van het sys- 
teemelement, terwijl het weghalen van de voet overeenkomt met het vrijgeven 
van het systeemelement. Er treedt een impasse op wanneer twee personen op 
dezelfde steen willen stappen. De impasse kan worden opgeheven als één van 
beide personen teruggaat naar de kant van de rivier waar hij vandaan kwam. In 
de taal van het besturingsysteem wordt deze terugtrekking terugkeer (Engels: 


ER 


Figuur 8.2 


Impassesituatie bij het oversteken van een rivier 
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rollback) genoemd. Let erop dat, als verscheidene personen de rivier van dezelfde 
zijde oversteken, het nodig kan zijn dat meer dan één persoon teruggaat om de 
impasse op te heffen. Als een persoon de rivier gaat oversteken zonder dat hij in 
de gaten heeft dat iemand anders de rivier van de andere kant probeert over te 
steken, is een impasse altijd mogelijk. 

De enige manier om er zeker van te zijn dat er geen impasse kan optreden 
is de eis te stellen dat ieder die de rivier oversteekt een algemeen aanvaard proto- 
col volgt. Zo’n protocol zou kunnen vereisen dat ieder die de rivier wil oversteken 
zich ervan vergewist dat niet iemand anders bezig is de rivier van de andere kant 
over te steken. Als dat inderdaad niet het geval is, mag hij gaan. Anders moet 
men wachten tot de persoon die van de andere kant komt de rivier overgestoken 
is. Er moeten naar aanleiding van dit protocol een paar opmerkingen worden 
gemaakt. 


@ We moeten een mechanisme hebben om te bepalen of iemand bezig is de rivier 
over te steken. Als het altijd mogelijk is de toestand van alle stenen te onder- 
zoeken, is deze voorwaarde voldoende. Zo niet (de rivier kan bijvoorbeeld te 
breed zijn, of mist kan het uitzicht belemmeren), dan is een ander mechanisme 
nodig. 

@ Stel dat twee personen de rivier tegelijk en van tegenovergestelde kanten willen 
oversteken. Ons protocol vermeldt niet wat er in dit geval gebeuren moet. Als 
beiden de rivier gaan oversteken zal er een impasse optreden. Als elk van bei- 
den erop wacht dat de ander begint, zal er een andere vorm van impasse optre- 
den. Een remedie voor deze moeilijkheid is één kant van de rivier (laten we 
zeggen, de oostelijke oever) voorrang te geven. Dat wil zeggen dat de persoon 
op de oostelijke oever altijd het eerst oversteekt, terwijl de persoon op de wes- 
telijke oever zal moeten wachten. 

@ Als dit protocol in acht genomen wordt, is het mogelijk dat er één of meer 
personen voor onbepaalde tijd moeten wachten om de rivier over te steken. 
Deze situatie wordt verhongering genoemd. Dit kan in het voorbeeld van het 
oversteken van de rivier vóórkomen als een voortdurende stroom mensen de 
rivier oversteekt van de kant die voorrang heeft. Om de garantie te geven dat 
verhongering niet kan vóórkomen, moet het vorige protocol worden uitge- 
breid. We kunnen bijvoorbeeld een algoritme definiëren dat de oversteekrich- 
ting van tijd tot tijd omkeert. Het ontwerpen van zo’n algoritme laten we ter 
oefening aan de lezer over. 


8.1.1 Systeemmodel 


Een systeem bestaat uit een eindig aantal systeemelementen die over een aantal 
met elkaar wedijverende processen moeten worden verdeeld. De systeemelemen- 
ten worden in diverse typen verdeeld, waarbij elk type uit een aantal identieke 
exemplaren bestaat. CVE-cycli, geheugenruimte, bestanden en randapparaten 
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(zoals printers, magneetbandeenheden en kaartlezers) zijn voorbeelden van sys- 
teemelement-typen. Als een systeem twee CVE’s heeft, bestaat het systeemele- 
ment-type CVE uit twee exemplaren. Evenzo kan het systeemelement-type prin- 
ter uit vijf exemplaren bestaan. 

Als een proces om een exemplaar van een systeemelement-type verzoekt, 
zal door de toewijzing van het geeft niet welk exemplaar aan het verzoek worden 
voldaan. Als dit niet zo is zijn de exemplaren niet identiek en heeft de klasse- 
indeling van de systeemelement-typen niet op de juiste wijze plaatsgevonden. Een 
systeem kan bijvoorbeeld twee printers hebben. Deze printers kunnen per defini- 
tie in dezelfde klasse van systeemelement-typen vallen als het geen mens kan 
schelen welk van beide zijn/haar uitvoer afdrukt. Echter, als één printer op de 
achtste verdieping staat en de andere staat in de kelder, dan zien de mensen op 
de achtste verdieping de beide printers waarschijnlijk niet als gelijkwaardig en 
kan het nodig zijn dat men afzonderlijke klassen van systeemelement-typen voor 
elk van beide printers moet definiëren. 

Een proces moet een systeemelement aanvragen voordat het dit gebruikt 
en moet het na gebruik weer vrijgeven. Een proces kan zoveel systeemelementen 
aanvragen als het nodig heeft om de eraan toegewezen taak uit te voeren. Het 
aantal aangevraagde systeemelementen kan natuurlijk niet het totale aantal sys- 
teemelementen dat in het systeem beschikbaar is te boven gaan. Met andere 
woorden, een proces kan niet drie printers aanvragen als het systeem er maar 
twee heeft. 

In een normale manier van werken kan een proces alleen in de onderstaan- 
de volgorde van een systeemelement gebruik maken: 


1. Aanvraag. Als aan het verzoek niet onmiddellijk kan worden voldaan (bijvoor- 
beeld als het systeemelement door een ander proces gebruikt wordt), moet het 
proces dat de aanvraag doet wachten tot het het systeemelement kan krijgen. 

2. Gebruik. Het proces kan met het systeemelement werken (als het systeemele- 
ment bijvoorbeeld een printer is, kan het proces op de printer afdrukken). 

3. Vrijgave. Het proces geeft het systeemelement vrij. 


Het aanvragen en weer vrijgeven van systeemelementen vindt plaats door 
middel van systeemaanroepen, zoals in paragraaf 2.2.1 is uiteengezet. Voorbeel- 
den van dit soort systeemaanroepen zijn: Vraag randapparaat aan/Geef randap- 
paraat vrij, Open/Sluit bestand, en Wijs geheugen toe/Geef geheugen vrij. Het 
gebruik van systeemelementen kan ook alleen plaatsvinden via systeemaanroe- 
pen (bijvoorbeeld het lezen of schrijven van of naar een bestand of randappa- 
raat). Daarom gaat het systeem voor elk gebruik na of het proces dat het systeem- 
element gebruikt dit systeemelement ook heeft aangevraagd en verkregen. Een 
systeemtabel legt van elk systeemelement vast of dit vrij is of toegewezen, en zo 
ja, aan welk proces. Als een proces een systeemelement aanvraagt, kan het wor- 
den toegevoegd aan een wachtrij van processen die staan te wachten tot het sys- 
teemelement vrijkomt. 


Hoofdstuk 8 Impasses 


8.1.2 Definitie van impasse 


Een groep processen verkeert in een impassesituatie wanneer elk proces in de 
groep wacht op een gebeurtenis die alleen kan worden veroorzaakt door een an- 
der proces in de groep. De gebeurtenissen waarmee we voornamelijk te maken 
hebben zijn het verkrijgen en vrijgeven van compütersysteemelementen. Er kun- 
nen echter ook andere soorten gebeurtenissen impasses tot gevolg hebben, zoals 
we zullen laten zien in de hoofdstukken 9 en 13. 

Laten we ter illustratie van een impassesituatie eens kijken naar een systeem 
met drie magneetbandeenheden. Stel dat er drie processen zijn die elk één van 
deze magneetbandeenheden bezet houden. Als elk proces nu nog een magneet- 
bandeenheid aanvraagt, zullen de drie processen zich in een impassesituatie be- 
vinden. Elk proces wacht op de gebeurtenis ’magneetbandeenheid is vrijgegeven’, 
die alleen kan worden veroorzaakt door één van de andere wachtende processen. 
Dit voorbeeld illustreert een impasse waarbij drie processen betrokken zijn die 
wedijveren om hetzelfde systeemelement-type. 

Bij impasses kunnen ook verschillende systeemelement-typen betrokken 
zijn. Neem bijvoorbeeld een systeem met één printer en één kaartlezer. Stel dat 
proces P de kaartlezer heeft en proces Q de printer. Als P nu de printer aanvraagt 
en Q de kaartlezer, dan hebben we een impasse. 


8.2 Impassekenmerken 


Impasses zijn natuurlijk niet gewenst. Tijdens een impasse komen processen niet 
klaar met hun uitvoering en worden systeemelementen bezet gehouden, zodat 
andere jobs niet de gelegenheid krijgen om zelfs ook maar te beginnen. Voordat 
we de verschillende methoden bespreken om het impasseprobleem te behandelen, 
is het misschien nuttig enige kenmerkende trekken van impasses te beschrijven. 


8.2.1 Noodzakelijke voorwaarden 


Een impassesituatie kan alleen dan optreden indien in een systeem tegelijkertijd 
aan de volgende vier voorwaarden is voldaan. 


e Wederzijdse uitsluiting. Ten minste één systeemelement wordt bezet gehouden 
dat niet gemeenschappelijk gebruikt wordt; dat wil zeggen, slechts één proces 
tegelijk kan het systeemelement gebruiken. Als een ander proces om dat sys- 
teemelement verzoekt, moet dat proces wachten tot het systeemelement is vrij- 
gegeven. 

@ Bezet-houden-en-wachten. Er moet een proces bestaan dat ten minste één sys- 
teemelement bezet houdt en dat tevens wacht op het verkrijgen van nog andere 
systeemelementen die op dat moment door andere processen bezet zijn. 
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@ Geen voortijdig ontnemen. Systeemelementen kunnen niet voortijdig worden 
afgenomen; dat wil zeggen dat een systeemelement alleen vrijwillig kan wor- 
den vrijgegeven door het proces dat dit systeemelement in bezit heeft, nadat 
het proces zijn taak beëindigd heeft. 

@ Wachten-in-een-kring. Er moet een verzameling {po, pi, … pn} van wachtende 
processen bestaan zodanig dat po wacht op een systeemelement dat in het bezit 
is van pi, pı wacht op een systeemelement dat in het bezit is van pz, … Pn-i 
wacht op een systeemelement dat in het bezit is van pn, en pn wacht weer op een 
systeemelement dat in het bezit is van po. 


We leggen er de nadruk op dat aan alle vier voorwaarden moet zijn voldaan wil 
een impasse optreden. De voorwaarde van het wachten-in-een-kring houdt de 
voorwaarde van het bezet-houden-en-wachten in, zodat de vier voorwaarden niet 
geheel onafhankelijk zijn. We zullen echter zien (in paragraaf 8.3) dat het heel 
nuttig is om iedere voorwaarde afzonderlijk te beschouwen. 

We kunnen deze vier voorwaarden zien in ons voorbeeld van het oversteken 
van een rivier. Er treedt dan en alleen dan een impasse op als twee mensen ko- 
mend van tegenovergestelde kanten van de rivier elkaar in het midden ontmoe- 
ten. Aan de voorwaarde van wederzijdse uitsluiting is uiteraard voldaan, aange- 
zien ten hoogste één persoon tegelijk op een steen kan stappen. Aan de voorwaar- 
de van het bezet-houden-en-wachten is voldaan, omdat iedereen op de ene steen 
stapt en wacht om op de volgende te stappen. Er is voldaan aan de voorwaarde 
van niet voortijdig ontnemen, omdat een steen niet met geweld aan de persoon 
die erop stapt ontnomen kan worden. Tenslotte is aan de voorwaarde van het 
wachten-in-een-kring voldaan, omdat de persoon die uit oostelijke richting komt 
wacht op de persoon die uit westelijke richting komt, terwijl de persoon die uit 
het westen komt op zijn beurt wacht op de persoon die uit het oosten komt. Geen 
van beiden kan verder gaan, en elk wacht erop dat de ander zijn voet van één 
van de stenen af zal halen. 


8.2.2 Graaf voor het toewijzen van systeemelementen 


Impasses kunnen nauwkeuriger worden beschreven met behulp van een gerichte 
graaf die een graaf voor het toewijzen van systeemelementen wordt genoemd. Deze 
graaf bestaat uit een paar G = (K,R), waarin K een verzameling knooppunten 
en R een verzameling relaties aangeduid door pijlen voorstelt. De verzameling 
van knooppunten wordt verdeeld in twee typen: P = (po, pi, … pn}, de verza- 
meling bestaande uit alle processen in het systeem, en S = {50, S1, … Sn}, de 
verzameling van alle systeemelement-typen in het systeem. 

Ieder element in de verzameling R van relaties (pijlen) is een geordend paar 
(Pisi) of (sj,pi), waarin p; een proces (p: € P) en s; een systeemelement-type is (s; € 
S). Als (pi,5;) € R, dan loopt er een pijl van proces p; naar systeemelement-type 
sj. Dit houdt in dat proces p; een exemplaar van systeemelement-type s; heeft 
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aangevraagd en op dit moment op dat systeemelement-type staat te wachten. Als 
(s;pi) € R, dan loopt er een pijl van systeemelement-type s; naar proces pi, hetgeen 
inhoudt dat een exemplaar van systeemelement-type s; toegewezen is aan proces 
pi. Een pijl (pi,s)) wordt een aanvraagpijl genoemd, terwijl een pijl (s‚‚p;) een toe- 
wijzingspijl wordt genoemd. 

Grafisch stellen we elk proces p; als een cirkeltje voor en elk syteemelement- 
type sj als een vierkantje. Omdat er meerdere exemplaren van systeemelement- 
type s; kunnen voorkomen, stellen we elk exemplaar als een stip binnen het vier- 
kantje voor. Let er op dat een aanvraagpijl slechts naar het vierkant s; wijst, 
terwijl een toewijzingspijl uit één van de stippen binnen het vierkant moet komen. 

Wanneer proces p; een exemplaar van syteemelement-type s; aanvraagt, 
wordt er een pijl in de graaf voor de toewijzing van systeemelementen bijge- 
tekend. Wanneer aan dit verzoek kan worden voldaan, wordt op hetzelfde moment 
de aanvraagpijl veranderd in een toewijzingspijl. Wanneer het proces later het 
systeemelement vrijgeeft, wordt de toewijzingspijl uitgewist. 

De graaf voor het toewijzen van systeemelementen in figuur 8.3 brengt de 
volgende situatie in beeld. 


@ De verzamelingen P, S en R: 
P = (pi, pa, p3} 


S = {S1, 82, 53, Sa} 


R = {pi,81), (p2,53), (Supa), (S2,p2), (S2,p1), (53,p3} 
@ Exemplaren van systeemelementen: 


O Eén exemplaar van systeemelement-type sı. 

O Twee exemplaren van systeemelement-type s2. 

O Eén exemplaar van systeemelement-type s3. 

O Drie exemplaren van systeemelement-type s4. 
@ Procestoestanden: 


O Proces pı houdt een exemplaar van systeemelement-type s2 bezet en wacht 
_op een exemplaar van systeemelement-type sı. 


O Proces p2 houdt een exemplaar van systeemelement-type si en van s2 bezet 
en wacht op een exemplaar van systeemelement-type s3. 


O Proces ps houdt een exemplaar van systeemelement-type s3 bezet. 


Op grond van de definitie van een graaf voor het toewijzen van systeemele- 
menten kan gemakkelijk worden aangetoond dat als de graaf geen lussen bevat, 
geen proces in het systeem in een impasse verkeert. Als daarentegen de graaf een 
lus bevat kan er een impasse bestaan. 
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S2 


Figuur 8.3 
Graaf voor het toewijzen van systeemelementen 


Als elk systeemelement-type precies één exemplaar bevat, betekent een lus 
dat er een impasse is opgetreden. Als de lus alleen betrekking heeft op een verza- 
meling systeemelementen die elk slechts één exemplaar hebben, is een impasse 
ingetreden. Elk proces dat aan de lus meedoet zit in een impasse. In dit geval 
betekent een lus in de graaf zowel een noodzakelijke als een voldoende voorwaar- 
de voor het bestaan van een impasse. Als elk type van systeemelementen verschil- 
lende exemplaren bezit, dan hoeft een lus niet noodzakelijk te betekenen dat er 
een impasse is opgetreden. In dit geval is een lus in de graaf een noodzakelijke, 
maar geen voldoende, voorwaarde voor het bestaan van een impasse. 

Laten we, ter illustratie van dit denkbeeld, teruggaan naar de graaf voor 
het toewijzen van systeemelementen in figuur 8.3. Stel dat het proces p3 een exem- 
plaar van het systeemelement-type s2 aanvraagt. Aangezien er geen exemplaar 
van dit systeemelement-type beschikbaar is, wordt een aanvraagpijl (p3, s2) aan 
de graaf toegevoegd (zie figuur 8.4). Op dit moment bestaan er in het systeem 
twee minimale lussen: 

Pr rn Pe PP? 33-3 o> 32 A. 


P2 > S3 > p3 > S2 —> pr 


De processen pi, p2 en p3 verkeren in een impasse. Proces p2 wacht op het systeem- 
element s3, dat door proces ps wordt vastgehouden. Proces p3 daarentegen wacht 
erop dat óf proces pi Of proces p2 systeemelement-type s2 zal vrijgeven. Intussen 
wacht proces p2 op proces ps. Bovendien wacht proces pi erop dat proces p2 sys- 
teemelement sı vrijgeeft. 

Kijk nu naar figuur 8.5. In dit voorbeeld hebben we ook een lus: 
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Figuur 8.4 
Graaf voor het toewijzen van systeemelementen waarin een impasse voorkomt 


Er is nu echter geen impasse. Merk op dat proces p4 zijn exemplaar van systeem- 
element-type s2 kan vrijgeven. Dat systeemelement kan dan worden toegewezen 
aan proces p3, waardoor de lus verbroken wordt. 

Samenvattend kunnen we zeggen dat, als een graaf voor het toewijzen van 
systeemelementen geen lus heeft, het systeem zich niet in een impassetoestand 
bevindt. Als er daarentegen een lus is, kan het systeem al of niet in een impasse- 
toestand verkeren. Deze constatering is belangrijk voor het behandelen van het 
impasseprobleem. 


Figuur 8.5 
Graaf voor het toewijzen van systeemelementen waarin wel een lus maar geen impasse voor- 
komt 
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8.2.3 Methoden voor het behandelen van impasses 


In principe zijn er twee methoden voor het behandelen van het impasseprobleem. 
We kunnen een of ander protocol hanteren om de zekerheid te geven dat het 
systeem nooit in een impassesituatie zal komen. De andere mogelijkheid is dat 
we het systeem kunnen toestaan in een impassesituatie te geraken en dat we daar 
dan weer uitkomen. Zoals we laten zien in figuur 8.6, kan het oplossen van impas- 
ses heel moeilijk en kostbaar zijn. Daarom bezien we eerst de methoden om te 
garanderen dat impasses nooit optreden. Er zijn twee veel gebruikte methoden: 
het voorkómen van impasses en het vermijden van impasses. 


8.3 Het voorkómen van impasses 


Zoals we in paragraaf 8.2.1 opmerkten, moet voor het optreden van een impasse 
aan elk van de vier noodzakelijke voorwaarden voldaan zijn. Door de zekerheid 
te geven dat aan ten minste één van deze voorwaarden niet voldaan kan worden, 
kunnen we het optreden van een impasse voorkómen. Laten we dieper op deze 
benaderingswijze ingaan door elk van de vier noodzakelijke voorwaarden afzon- 
derlijk te bekijken. 


8.3.1 Wederzijdse uitsluiting 


De voorwaarde van wederzijdse uitsluiting moet gelden voor typen systeemele- 
menten die niet voor gemeenschappelijk gebruik bestemd zijn. Een printer bij- 
voorbeeld kan niet door verschillende processen tegelijkertijd gebruikt worden. 
Systeemelementen bestemd voor gemeenschappelijk gebruik daarentegen verei- 
sen geen toegang met wederzijdse uitsluiting en kunnen daarom geen impasse 
opleveren. Alleen-uitleesbare (read-only) bestanden vormen een goed voorbeeld 
van een systeemelement met gemeenschappelijk gebruik. Als verschillende 
processen op hetzelfde moment een alleen-uitleesbaar bestand trachten te 
openen, kunnen ze gelijktijdige toegang tot het bestand krijgen. Een proces be- 
hoeft nooit op een systeemelement voor gemeenschappelijk gebruik te wachten. 
In het algemeen is het echter niet mogelijk impasses te voorkómen door af te zien 
van de voorwaarde van de wederzijdse uitsluiting. Sommige systeemelementen 
zijn intrinsiek niet bestemd voor gemeenschappelijk gebruik. 


8.3.2 Bezet-houden-en-wachten 
Om er zeker van te zijn dat nooit aan de voorwaarde van bezet-houden-en-wach- 


ten wordt voldaan, moeten we de garantie geven dat wanneer een proces een 
systeemelement aanvraagt, het geen andere systeemelementen in zijn bezit heeft. 
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Eén van de protocollen die men kan gebruiken vereist dat elk proces al zijn sys- 
teemelementen aanvraagt en toegewezen krijgt vóórdat het aan zijn uitvoering 
begint. Deze voorziening kan worden geïmplementeerd door te eisen dat systeem- 
aanroepen voor het aanvragen van systeemelementen aan alle andere systeem- 
aanroepen voorafgaan. 

Een ander mogelijk protocol staat een pfoces toe alleen dan om systeemele- 
menten te verzoeken wanneer het geen enkel systeemelement heeft. Een proces 
kan enkele systeemelementen aanvragen en deze gebruiken. Voordat het evenwel 
nog weer andere systeemelementen kan aanvragen, moet het alle systeemelemen- 
ten die op dat ogenblik aan het proces zijn toegewezen vrijgeven. 

Laten we, om het verschil tussen deze protocollen toe te lichten, een proces 
beschouwen dat van een kaartlezer naar een schijvenbestand kopieert, het schij- 
venbestand sorteert, en dan de resultaten op een printer afdrukt en ze naar een 
magneetband wegschrijft. Als alle systeemelementen aan het begin van het proces 
moeten worden aangevraagd, moet het proces bij het begin de kaartlezer, het 
schijvenbestand, de printer en de magneetbandeenheid aanvragen. Het zal gedu- 
rende zijn gehele uitvoering de magneetbandeenheid vasthouden, hoewel het deze 
alleen aan het einde van de uitvoering nodig heeft. 

De tweede methode staat het proces toe aanvankelijk alleen de kaartlezer 
en het schijvenbestand aan te vragen. Het kopieert van de kaartlezer naar de 
schijf en geeft dan zowel de kaartlezer als het schijvenbestand vrij. Het proces 
moet dan opnieuw het schijvenbestand aanvragen en ook de printer. Na het 
kopiëren van het schijvenbestand naar de printer, geeft het beide vrij en vraagt 
dan het schijvenbestand nogmaals aan en nu tevens de magneetbandeenheid. Het 
kopieert het schijvenbestand naar de magneetband, geeft vervolgens de beide 
typen systeemelementen vrij en beëindigt zijn uitvoering. 

Aan deze protocollen kleven twee belangrijke bezwaren. Ten eerste kan er 
sprake zijn van een zeer lage systeemelement-gebruiksfactor, omdat het mogelijk 
is dat systeemelementen gedurende lange tijd wel toegewezen zijn maar niet ge- 
bruikt worden. In het gegeven voorbeeld kunnen we bijvoorbeeld de kaartlezer 
en het schijvenbestand vrijgeven, waarna we alleen het schijvenbestand en de 
printer aanvragen als we er zeker van zijn dat onze gegevens in het schijvenbe- 
stand intact blijven. Als dit niet zeker is, moeten we in beide protocollen alle 
systeemelementen bij het begin aanvragen. | 

Ten tweede is verhongering mogelijk. Een proces dat verschillende veel ge- 
vraagde systeemelementen nodig heeft, kan voor onbepaalde tijd moeten wach- 
ten, waarbij ten minste één van de systeemelementen die het proces nodig heeft 
steeds aan een ander proces is toegewezen. 


8.3.3 Geen voortijdig ontnemen 


De derde noodzakelijke voorwaarde is dat systeemelementen die al zijn toegewe- 
zen niet voortijdig ontnomen worden. Om er zeker van te zijn dat aan deze voor- 
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waarde niet is voldaan, kan het volgende protocol worden gebruikt. Als een pro- 
ces dat een aantal systeemelementen in zijn bezit heeft een aanvraag doet voor 
nog een systeemelement dat niet onmiddellijk aan dat proces kan worden toe- 
gewezen (dat wil zeggen dat het proces moet wachten), worden alle systeemele- 
menten die het op dat moment in zijn bezit heeft voortijdig aan het proces ontno- 
men. Dat wil zeggen, deze systeemelementen worden impliciet vrijgegeven. De 
voortijdig ontnomen systeemelementen worden aan de lijst van systeemelemen- 
ten waarop het proces staat te wachten toegevoegd. Het proces zal alleen dan 
opnieuw worden gestart wanneer het al zijn oude systeemelementen, alsook de 
nieuwe waarom het gevraagd heeft, kan (terug)krijgen. 

Een andere manier is dat, als een proces een aanvraag doet voor een aantal 
systeemelementen, we eerst controleren of deze beschikbaar zijn. Zo ja, dan wij- 
zen we deze toe. Als ze niet bechikbaar zijn, controleren we of ze zijn toegewezen 
aan een ander proces dat op meer systeemelementen wacht. Zo ja, dan ontnemen 
we de gewenste systeemelementen voortijdig aan het proces dat staat te wachten 
en wijzen ze toe aan het proces dat de aanvraag deed. Als de systeemelementen 
niet beschikbaar zijn en ook niet worden vastgehouden door een proces dat staat 
te wachten, moet het proces dat de aanvraag deed wachten. Terwijl het staat te 
wachten kunnen sommige van zijn systeemelementen voortijdig worden ontno- 
men, maar alleen als een ander proces deze aanvraagt. Een proces kan alleen 
weer worden gestart wanneer het de aangevraagde systeemelementen toegewezen 
heeft gekregen en ook de systeemelementen terug heeft gekregen die het door 
voortijdig ingrijpen verloren had terwijl het stond te wachten. 

Dit protocol wordt vaak toegepast op systeemelementen waarvan de status 
gemakkelijk kan worden opgeborgen en later hersteld, zoals de registers van de 
CVE en geheugenruimte. Het kan niet algemeen worden toegepast op systeemele- 
menten zoals printers, kaartlezers of magneetbandeenheden. In het THE- 
systeem (Bron [1972]) kon echter de printer voortijdig worden ontnomen. Er 
werd uitgegaan van de veronderstelling dat, als de printer voortijdig werd ontno- 
men en de uitvoer van twee jobs daarom dooreenliep, de operateur de afgedrukte 
pagina’s wel zou uitzoeken. 


8.3.4 Wachten-in-een-kring 


Om te garanderen dat aan de voorwaarde van het wachten-in-een-kring nooit is 
voldaan, kunnen we de regel van een absolute rangorde van alle systeemelement- 
typen opleggen. Dat wil zeggen, we kennen aan elk type systeemelement een 
uniek geheel getal toe, dat ons in staat stelt twee systeemelementen met elkaar te 
vergelijken en te bepalen of het ene element in onze rangorde aan het andere 
voorafgaat. In meer formele zin, laat S = {s1, 52, … sn} de verzameling van 
systeemelement-typen zijn. We kunnen een één-op-één relatie F: S — N definië- 
ren, waarin N de verzameling van de natuurlijke getallen is. Bijvoorbeeld, als tot 
het type S de systeemelementen schijfeenheden, magneetbandeenheden, kaart- 
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lezers en printers behoren, dan zou de functie F als volgt kunnen worden gedefi- 
nieerd: 


F(kaartlezer) 
F(magneetbandeenheid) = 
F(schijfeenheid) 
F(printer) = | 


ll 
NO N U m 


Laten we nu eens kijken naar het volgende protocol om impasses te voorkómen: 
elk proces kan slechts systeemelementen in oplopende volgorde van hun functie- 
waarde aanvragen. Dat wil zeggen, een proces kan in het begin elk gewenst aantal 
exemplaren van een systeemelement-type, zeg si, aanvragen. Daarna kan het pro- 
ces dan en alleen dan exemplaren van het systeemelement-type s; aanvragen, als 
F(s) > F(s;). Als verschillende exemplaren van hetzelfde type systeemelementen 
nodig zijn, moet één enkele aanvraag voor alle elementen worden gedaan. Bij- 
voorbeeld, bij gebruikmaking van de bovenstaande functie moet een proces dat 
de kaartlezer en de printer tegelijk wil gebruiken, eerst de kaartlezer en dan de 
printer aanvragen. 

We kunnen ook eisen dat, wanneer een proces een exemplaar van het sys- 
teemelement-type s; aanvraagt, het alle systeemelementen van het type si, waar- 
voor geldt dat F(s:) > F(s;), heeft vrijgegeven. 

Als deze protocollen worden gebruikt, kan aan de voorwaarde van het 
wachten in een kring niet worden voldaan. We kunnen dit feit aantonen door 
aan te nemen dat er een situatie van wachten-in-een-kring bestaat (bewijs uit het 
ongerijmde). Laat de verzameling van processen die in een kring op elkaar wach- 
ten bestaan uit (po, pi, … Pn}, waarbij pi wacht op systeemelement si, dat wordt 
vastgehouden door proces pi+1. (We rekenen modulo de indices, zodat pn wacht 
op een systeemelement sn, dat zelf weer wordt vastgehouden door po.) Dan moet, 
aangezien proces pi+1 wacht op systeemelement si, terwijl dit proces systeemele- 
ment sj+1 aanvraagt, F(s) < F(si+1) gelden voor alle i. Maar dit betekent dat 
F(so) < F(si) < … < F(sn) < F(so). Vanwege de transitieve eigenschap geldt 
dan F(so) < F(so), wat onmogelijk is. Daarom kan er geen wachten in een kring 
optreden. 

Er moet worden opgemerkt dat de functie F volgens de normale ge- 
bruiksvolgorde van de systeemelementen moet worden gedefinieerd. Bijvoor- 
beeld, omdat de kaartlezer gewoonlijk vóór de printer nodig is, zou het redelijk 
zijn per definitie te stellen dat F(kaartlezer) < F(printer). 


8.4 Het vermijden van impasses 
Algoritmen ter voorkoming van impasses, zoals zojuist besproken in paragraaf 


8.3, voorkomen impasses door beperkingen op te leggen aan de manier waarop 
aanvragen kunnen worden gedaan. De beperkingen garanderen dat ten minste 
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één van de noodzakelijke voorwaarden voor impasses niet kan optreden, en dien- 
tengevolge dat impasses niet vóórkomen. Een bijverschijnsel evenwel van het 
voorkómen van impasses door deze methode is eventueel een lage randapparaat- 
gebruiksfactor en een verminderde doorvoercapaciteit van het systeem. 

Een andere methode voor het vermijden van impasses is extra informatie 
te verlangen over hoe systeemelementen aangevraagd moeten worden. Bijvoor- 
beeld, in een systeem met één kaartlezer en één printer zouden we te horen kun- 
nen krijgen dat proces P eerst de kaartlezer zal aanvragen en later de printer, 
alvorens beide systeemelementen weer vrij te geven. Proces Q daarentegen zal 
eerst de printer en dan de kaartlezer aanvragen. Met deze kennis van de complete 
volgorde van het aanvragen en weer vrijgeven voor elk proces kunnen we voor 
iedere aanvraag beslissen of het proces moet wachten of niet. Iedere aanvraag 
vereist dat het systeem nagaat welke systeemelementen op dat moment beschik- 
baar zijn, welke systeemelementen op dat moment aan ieder proces zijn toegewe- 
zen, en wat elk proces in de toekomst zal aanvragen en vrijgeven, om te kunnen 
beslissen of aan de huidige aanvraag kan worden voldaan of dat deze moet wach- 
ten om een eventuele toekomstige impasse te voorkómen. 

Er zijn diverse algoritmen die verschillen in de hoeveelheid en het soort 
informatie dat verlangd wordt. Het eenvoudigste en bruikbaarste model verlangt 
dat ieder proces het maximumaantal systeemelementen van elk type dat het nodig 
kan hebben opgeeft. Op grond van deze a priori informatie voor elk proces, over 
het maximumaantal systeemelementen van elk type dat kan worden aangevraagd, 
is het mogelijk een algoritme op te stellen dat garandeert dat het systeem nooit 
in een impassesituatie zal komen. Dit algoritme definieert de methode van het 
vermijden van impasses. Een algoritme om impasses te vermijden onderzoekt dy- 
namisch de toestand van de toewijzing van systeemelementen om de zekerheid 
te geven dat de voorwaarde van het wachten in een kring nooit zal optreden. De 
toestand van de toewijzing van systeemelementen wordt bepaald door het aantal 
beschikbare en toegewezen systeemelementen, en het maximumaantal aanvragen 
van elk der processen. Een toestand is veilig als het systeem aan elk proces 
systeemelementen (hoogstens het maximumaantal) in een of andere volgorde kan 
toewijzen en daarbij nog steeds een impasse kan vermijden. 

Formeler uitgedrukt, een systeem bevindt zich alleen dan in een veilige toe- 
stand als er een veilige volgorde is. Een reeks processen <pi, p2, … , pn>> is een 
veilige reeks voor de huidige toewijzingstoestand als voor elk proces p; geldt dat 
de systeemelementen die p; nog kan aanvragen kunnen worden toegewezen met 
behulp van de op dat moment beschikbare systeemelementen plus de systeemele- 
menten die in het bezit zijn van al de processen p;, waarbij j < i. In deze situatie 
zou proces pi, indien de systeemelementen die p; nodig heeft niet onmiddellijk 
beschikbaar zijn, kunnen wachten tot alle processen p; klaar zijn. Wanneer deze 
klaar zijn, kan p; al zijn benodigde systeemelementen krijgen, zijn aangewezen 
taak voltooien, zijn toegewezen systeemelementen teruggeven en eindigen. Wan- 
neer p; eindigt, kan p;+1 zijn benodigde systeemelementen krijgen, enzovoort. Als 
zo’n volgorde niet bestaat, zegt men dat het systeem onveilig is. 
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Een veilige toestand is geen impassesituatie. Omgekeerd is een impasse- 
situatie een onveilige toestand. Echter, niet alle onveilige toestanden zijn impas- 
sesituaties (zie figuur 8.6). Een onveilige toestand kan tot een impasse leiden. 
Zolang de toestand veilig is, kan het besturingssysteem onveilige toestanden (en 
dus impassesituaties) vermijden. In een onveilige toestand kan het besturingssys- 
teem niet verhinderen dat processen zodanig systeemelementen aanvragen dat 
een impasse optreedt: het gedrag van de processen bepaalt of er onveilige toe- 
standen opreden of niet. 

Om dit toe te lichten bezien we een systeem met twaalf magneetbandeenhe- 
den en drie processen: po, pi en p2. Proces po heeft tien magneetbandeenheden 
nodig, proces pı heeft er hoogstens vier nodig en proces p2 maximaal negen. Stel 
dat op het tijdstip To proces po vijf magneetbandeenheden heeft, proces pı twee 
en proces p2 ook twee. (Dus zijn er drie vrije magneetbandeenheden.) 


Maximumbehoefte Huidige behoefte 


Po 10 5 
Pi 4 2 
p2 9 2 


Op tijdstip To bevindt het systeem zich in een veilige toestand. De volgorde 
<pı, po, p2> voldoet aan de voorwaarde van veiligheid, daar aan proces pı 
onmiddellijk al zijn magneetbandeenheden toegewezen kunnen worden en p: ze 
daarna kan teruggeven (het systeem heeft dan tien beschikbare magneetbandeen- 
heden), en tenslotte zou proces p2 al zijn magneetbandeenheden kunnen krijgen 


onveilig 


Figuur 8.6 
Veilige-, onveilige- en impasse-toestandsruimten 
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en ze teruggeven. (Het systeem heeft dan alle twaalf magneetbandeenheden be- 
schikbaar.) 

Merk op dat het mogelijk is van een veilige naar een onveilige toestand te 
gaan. Stel dat op het tijdstip Tı proces p2 nog een magneetbandeenheid aanvraagt 
en toegewezen krijgt. Het systeem bevindt zich niet langer in een veilige toestand. 
Op dit moment kan alleen proces pı al zijn magneetbandeenheden toegewezen 
krijgen. 

Wanneer het deze teruggeeft zal het systeem slechts vier beschikbare mag- 
neetbandeenheden hebben. Omdat proces po vijf magneetbandeenheden heeft, 
met een maximumaantal van tien, kan het er nog vijf bij vragen. Omdat deze niet 
beschikbaar zijn, moet proces po wachten. Evenzo kan proces p2 nog eens zes 
magneetbandeenheden aanvragen en moeten wachten, wat een impasse tot gevolg 
heeft. 

De vergissing die we hebben gemaakt is dat we voldoen aan het verzoek 
van proces p2 voor nog een magneetbandeenheid. Als we p2 hadden laten wachten 
tot één van de beide andere processen klaar was en zijn systeemelementen had 
vrijgegeven, hadden we de impassesituatie kunnen vermijden. 

Ons baserend op het idee van een veilige toestand, kunnen we algoritmen 
ter vermijding van impasses definiéren die garanderen dat het systeem nooit in 
een impasse zal komen. De gedachte hierachter is simpelweg te garanderen dat 
het systeem altijd in een veilige toestand zal blijven. Aanvankelijk bevindt het 
systeem zich in een veilige toestand. Telkens wanneer een proces een aanvraag 
doet voor een systeemelement dat op dat moment beschikbaar is, moet het sys- 
teem beslissen of het systeemelement onmiddellijk kan worden toegewezen of dat 
het proces moet wachten. Aan het verzoek wordt alleen voldaan als daardoor het 
systeem in een veilige toestand wordt gelaten. 

Let erop dat bij deze methode een proces mogelijk toch moet wachten als 
het een systeemelement aanvraagt dat op dat moment wel beschikbaar is. Op die 
manier kan de gebruiksfactor van de systeemelementen lager zijn dan zonder 
algoritme ter vermijding van impasses. 


8.4.1 Verschillende exemplaren van een systeemelement-type 


Het algoritme om impasses te vermijden dat we hierna zullen beschrijven staat 
algemeen bekend als het bankiersalgoritme. Deze naam werd gekozen omdat dit 
algoritme in het systeem van een bank zou kunnen worden gebruikt om te garan- 
deren dat de bank het beschikbare kapitaal nooit zodanig toewijst dat hij niet 
langer aan de behoeften van al zijn cliënten kan voldoen. 

Wanneer een nieuw proces het systeem binnenkomt, moet het het maxi- 
mumaantal exemplaren opgeven dat het van elk systeemelement-type nodig zou 
kunnen hebben. Dit aantal mag het totale aantal systeemelementen niet over- 
schrijden. Wanneer een gebruiker een stel systeemelementen aanvraagt, moet 
worden vastgesteld of de toewijzing van deze systeemelementen het systeem in 
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een veilige toestand laat. Zo ja, dan worden de systeemelementen toegewezen; 
anders moet het proces wachten tot een ander proces genoeg systeemelementen 
vrijgeeft. 

Er moeten diverse gegevensstructuren worden bijgehouden om het 
bankiersalgoritme te implementeren. Deze gegevensstructuren beschrijven de 
toestand van het systeem van toewijzing van systeemelementen. Als n het aantal 
processen in het systeem voorstelt en m het aantal systeemelement-typen, dan 
hebben we de volgende gegevensstructuren nodig: 


@ Beschikbaar. Een vector met lengte m geeft het aantal beschikbare systeemele- 
menten van elk type aan. Als Beschikbaar{j] = k, zijn er k exemplaren van 
systeemelement-type s; beschikbaar. 

@ Maximum. Een n X m matrix die de maximumbehoefte van elk proces aan- 
geeft. Als Maximunfi,] = k, kan proces pj ten hoogste k exemplaren van 
systeemelement-type s; aanvragen. 

@ Toewijzing. Een n X m matrix die het aantal systeemelementen van elk type 
aangeeft dat aan elk proces is toegewezen. Als Toewijzing[i,j] = k, dan zijn aan 
proces p; op dit moment k exemplaren van systeemelement-type s; toegewezen. 

© Behoefte. Een n X m matrix die de resterende behoefte van elk proces aangeeft. 
Als Behoefte[i,j] = k, dan kan proces p: nog k exemplaren van systeemelement- 
type s; nodig hebben voor het voltooien van zijn taak. Merk op dat Behoef- 
telij) = Maximumlij} — Toewijzinglij). 


Deze gegevensstructuren variëren zowel in grootte als in waarde naarmate de tijd 
voortschrijdt. 

Laten we, om de presentatie van het algoritme te vereenvoudigen, een nota- 
tie afspreken. Laten X en Y vectoren voorstellen met lengte n. We zeggen dat 
dan en alleen dan X < Y als Xļi] < Y[i] voor alle i = 1, 2, … n. Bijvoorbeeld, 
als X = (1,7,3,2) en Y = (0,3,2,1), dan geldt Y < X. Ook geldt: Y < X, als Y 
< Xen Y # X. 

We kunnen nu elke rij in de matrices Toewijzing en Behoefte als vectoren 
behandelen en naar ze verwijzen als respectievelijk Toewijzing: en Behoeftei. Toe- 
wijzingi omschrijft de systeemelementen die momenteel aan proces p; zijn toe- 
gewezen, terwijl Behoefte; de systeemelementen aangeeft die proces p; verder nog 
kan aanvragen voor het vervullen van zijn taak. 


Het bankiersalgoritme 

Laat Aanvraag: de aanvraag-vector voor proces p; zijn. Als Aanvraag{j] = k, dan 
verlangt proces pi k exemplaren van systeemelement-type sj. Wanneer proces pi 
een aanvraag voor systeemelementen doet, worden de volgende acties onderno- 
men: 


1. Als Aanvraag: < Behoeftei, ga dan naar stap 2. Anders hebben we een fout, 
omdat het proces zijn maximumaantal heeft overschreden. 
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. Als Aanvraag; < Beschikbaar, ga dan naar stap 3. Anders zijn de systeemele- 


menten niet beschikbaar en moet proces p; wachten. 


- Het systeem doet net alsof het de gevraagde systeemelementen aan proces pi 


heeft toegewezen door de toestand als volgt te wijzigen. 


Beschikbaar := Beschikbaar — Aanvraagi; 
Toewijzing; := Toewijzing; + Aanvraag;; 
Behoefte; := Behoefte: — Aanvraag;; 


Als de daarmee corresponderende toewijzing van systeemelementen veilig is, 
wordt de transactie doorgevoerd en krijgt proces p; zijn systeemelementen toe- 
gewezen. Als echter de nieuwe toestand onveilig is, moet proces pi wachten tot 
aan Aanvraag; voldaan kan worden en wordt de oude toewijzingssituatie van 
systeemelementen hersteld. | 


Veiligheidsalgoritme 
Het algoritme om na te gaan of een systeem zich in een veilige toestand bevindt 
of niet, kan als volgt worden beschreven: 


E 


Laten Werk en Klaar vectoren voorstellen met lengte m respectievelijk n. Geef 
deze vectoren de beginwaarden: Werk := Beschikbaar en Klaar{i] := false 
voor i = 1, 2, … n. 


. Vind een i zodanig dat: 


a. Klaar{i] = false, en 
b. Behoefte: < Werk. 


Als geen enkele i voldoet, ga naar stap 4. 


. Werk := Werk + Toewijzing; 


Klaar{i] := true 
ga naar stap 2. 


. Als Klaar{i] = true voor alle i, dan bevindt het systeem zich in een veilige 


toestand. 


Een voorbeeld 

Beschouw een systeem met vijf processen {po, pi, … p4} en drie systeemelement- 
typen (A, B, C}. Systeemelement-type A heeft tien exemplaren, systeemelement- 
type B heeft vijf exemplaren en systeemelement-type C heeft zeven exemplaren. 
Stel dat op tijdstip To de volgende momentopname van het systeem wordt ge- 
maakt: 
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Toewijzing Maximum Beschikbaar 


ABC ABC ABC 
po 010 153 332 
pi 200 322 
p 302 902 
p? 211 422 
pi EOD 433 


De inhoud van de matrix Behoefte is per definitie Maximum — Toewijzing en is: 


Behoefte 

ABC 
po. T3 
p! r22 
p2 600 
P3 011 
p4 431 


We stellen dat het systeem zich momenteel in een veilige toestand bevindt. Inder- 
daad voldoet de volgorde <pı, p3 ps, p2, po> aan de veiligheidscriteria. 

Stel nu dat proces pı nog een exemplaar van systeemelement-type A en twee 
exemplaren van systeemelement-type C aanvraagt, dus Aanvraag: = (1,0,2). Om 
te beslissen of aan dit verzoek onmiddellijk kan worden voldaan, controleren we 
eerst of Aanvraag: < Beschikbaar, (dat wil zeggen (1,0,1) < (3,2,2)), wat inder- 
daad het geval is. Dan doen we alsof aan het verzoek voldaan is en komen zo tot 
de volgende nieuwe toestand: | 

Toewijzing Maximum Beschikbaar 


ABC ABC ABC 
po 010 743 230 
pi 302 020 
p 302 600 
pP 211 011 
pe 02 431 


We moeten bepalen of deze nieuwe toestand van het systeem veilig is. Daar- 
toe voeren we ons veiligheidsalgoritme uit en vinden zo dat de volgorde <pi, p3, 
pa, po, p2> voldoet aan ons veiligheidscriterium. Daarom kunnen we onmiddellijk 
aan de aanvraag van proces p: voldoen. 

U moet echter kunnen zien dat in deze toestand een aanvraag voor (3,3,0) 
door pa niet gehonoreerd kan worden, omdat de systeemelementen niet beschik- 
baar zijn. Aan een aanvraag voor (0,2,0) door po kan evenmin worden voldaan, 
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hoewel de systeemelementen beschikbaar zijn, omdat de daaruit resulterende toe- 
stand onveilig is. 


8.4.2 Eén exemplaar van elk systeemelement-type 


Hoewel het bankiersalgoritme heel algemeen is en voor elk systeem voor toe- 
wijzing van systeemelementen zal werken, kunnen er m X n? bewerkingen nodig 
zijn. Als we een systeem voor toewijzing van systeemelementen hebben met 
slechts één exemplaar van elk systeemelement-type, kan een efficiënter algoritme 
worden opgesteld. 

Dit algoritme maakt gebruik van een variant van de graaf voor de toe- 
wijzing van systeemelementen die in paragraaf 8.2.2 werd gedefinieerd. Naast 
de aanvraag- en toewijzingspijlen introduceren we een nieuw type pijl die we 
aanspraakpijl noemen. Een aanspraakpijl (pi,5;) geeft aan dat proces p; systeemele- 
ment s; op een zeker toekomstig moment kan aanvragen. Deze pijl lijkt op de 
aanvraagpijl voor wat de richting betreft, maar wordt voorgesteld als een onder- 
broken lijn. Wanneer proces p; systeemelement s; aanvraagt, wordt de aanspraak- 
pijl (pi,s;) omgezet in een aanvraagpijl. Evenzo wordt, wanneer een systeemele- 
ment s; door p; wordt vrijgegegeven, de toewijzingspijl (s;p:) omgezet in een aan- 
spraakpijl (p:,s;). We merken op dat in het systeem vooraf aanspraken op systeem- 
elementen gemaakt moeten worden. Dat wil zeggen, voordat proces p; aan zijn 
uitvoering begint, moeten zijn aanspraakpijlen al in de graaf voor het toewijzen 
van systeemelementen vóórkomen. Deze voorwaarde kan minder stringent wor- 
den gemaakt door toe te staan dat een aanspraakpijl (pi,s;) alleen dan aan de 
graaf moet worden toegevoegd als alle pijlen behorend bij proces p; aanspraak- 
pijlen zijn. 

Stel dat proces p; systeemelement s; aanvraagt. Aan de aanvraag kan alleen 
dan worden voldaan als het omzetten van de aanvraagpijl (pi,s;) in een toe- 
wijzingspijl (sj,pi) geen lus in de graaf voor de toewijzing van systeemelementen 
oplevert. Let erop dat de controle op veiligheid gedaan wordt door gebruik te 
maken van een algoritme voor het opsporen van lussen. Een algoritme voor het 
opsporen van een lus in deze graaf vereist een aantal bewerkingen in de orde van 
n°, waarin n het aantal processen in het systeem is. 

Als er geen lus bestaat, zal de toewijzing van het systeemelement het sys- 
teem in een veilige toestand laten. Wordt een lus gevonden, dan zal de toewijzing 
het systeem in een onveilige toestand brengen. Daarom zal proces p; moeten 
wachten tot aan zijn aanvraag kan worden voldaan. 

Laten we, ter illustratie van dit algoritme, eens kijken naar de graaf voor 
het toewijzen van systeemelementen van figuur 8.7. Stel dat p2 systeemelement s2 
aanvraagt. Hoewel s2 momenteel vrij is, kunnen we het niet aan pz toewijzen, 
omdat deze actie een lus in de graaf zal veroorzaken (zie figuur 8.8). Een lus geeft 
aan dat het systeem zich in een onveilige toestand bevindt. Als pı dan sz aan- 
vraagt, zal er een impasse optreden. 
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Figuur 8.7 
Het vermijden van impasses met behulp van een graaf voor het toewijzen van systeemele- 
menten 


8.5 Het opsporen van impasses 


Als een systeem geen protocol gebruikt dat garandeert dat nooit een impasse zal 
optreden, moet een methode voor het opsporen en oplossen van impasses worden 
geïmplementeerd. Een algoritme dat de toestand van het systeem inspecteert 
wordt periodiek aangeroepen om te bepalen of er een impasse is ontstaan. Zo ja, 
dan moet het systeem een poging in het werk stellen de impasse op te lossen. 
Daartoe moet het systeem: 


a. Informatie bijhouden over de huidige toewijzing van systeemelementen aan 
processen en ook over eventuele aanvragen voor de toewijzing van systeemele- 
menten waaraan nog niet voldaan is. 


b. Een algoritme leveren dat deze informatie benut om vast te stellen of het 
systeem in een impassesituatie is gekomen. 


In de volgende paragrafen zullen we uitvoeriger ingaan op de kwesties (a) en 
(b), omdat zij betrekking hebben op systemen met diverse exemplaren van elk 
systeemelement-type, alsook op systemen met slechts één enkel exemplaar van 
elk systeemelement-type. Laten we op dit punt aangekomen echter opmerken 
dat een algoritme voor het opsporen en oplossen van impasses overhead vereist 
waaronder niet alleen de kosten vallen van het tijdens de uitvoering bijhouden 
van de noodzakelijke informatie en het uitvoeren van het opsporingsalgoritme, 
maar ook de potentiële verliezen die inherent zijn aan het oplossen van een im- 
passe. 


8.5.1 Verschillende exemplaren van een systeemelement-type 


Het opsporingsalgoritme maakt gebruik van tijdafhankelijke gegevensstructuren 


8.5 Het opsporen van impasses 299 


Figuur 8.8 | 
Een onveilige toestand in een graaf voor het toewijzen van systeemelementen 


die veel lijken op die welke in het bankiersalgoritme worden gebruikt (zie para- 
graaf 8.4.1). 


@ Beschikbaar. Een vector met lengte m, die het aantal beschikbare systeemele- 
menten van elk type aangeeft. 

@ Toewijzing. Een matrix van n bij m, die het aantal systeemelementen van elk 
type aangeeft dat op dat moment aan elk proces is toegewezen. 

@ Aanvraag. Een matrix van n bij m, die de huidige aanvrage van elk proces 
aangeeft. Als Aanvraag(ij) = k, dan verzoekt proces p; om nog k exemplaren 
van systeemelement-type s;. 


De ‘kleiner dan’-relatie (<) tussen twee vectoren wordt gedefinieerd zoals 
in paragraaf 8.4. Om de notatie te vereenvoudigen zullen we de rijen in de Toe- 
wijzing- en Aanvraag-matrices weer als vectoren behandelen en ernaar verwijzen 
als respectievelijk Toewijzing; en Aanvraag. Het opsporingsalgoritme dat hierna 
beschreven wordt is te danken aan Shoshani en Coffman [1970]. Het algoritme 
onderzoekt gewoon iedere mogelijke volgorde van toewijzingen voor de processen 
die nog voltooid moeten worden. Vergelijk dit algoritme met het bankiersalgorit- 
me uit paragraaf 8.4.1. 


l. Laten Werk en Klaar vectoren zijn met lengte m respectievelijk n. Geef Werk 
de beginwaarde Beschikbaar. Maak Klaar{i] voor i = 1, 2, ..., n gelijk aan false 
als Toewijzing # 0; maak anders Klaar{i] gelijk aan true. 

2. Vind een index i zo dat: 


a. Klaar|i] = false en 
b. Aanvraagi < Werk. 


Als zo’n i niet bestaat, ga dan naar stap 4. 
3. Werk := Werk + Toewijzing: 

Klaar{i] := true 

ga naar stap 2. 
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4. Als Klaar[i] = false voor een i zodanig dat 1 < i < n, dan is het systeem 
in een impassesituatie. Bovendien bevindt proces pi zich in een impasse als 
Klaar{i] = false. 


U vraagt zich misschien af waarom we de systeemelementen van proces pi 
terugvorderen zodra we ontdekken dat Aanvraag; < Werk. We weten dat p; zich 
momenteel niet in een impasse bevindt. Daarom bezien we de zaak optimistisch 
en nemen we aan dat p; niet nog meer systeemelementen nodig zal hebben om 
zijn taak te voltooien; het zal daarom al zijn systeemelementen aan het systeem 
teruggeven. Is dit niet het geval, dan kan later een impasse optreden die dan 
de volgende keer dat het algoritme voor het opsporen van een impasse wordt 
aangeroepen ontdekt zal worden. 


Een voorbeeld 

Neem een systeem met vijf processen {po, pı, ..., p4} en drie systeemelement-typen 
(A, B, C). Systeemelement-type A heeft zeven exemplaren, systeemelement-type 
B heeft twee exemplaren en systeemelement-type C heeft zes exemplaren. Stel 


dat we op tijdstip To we de volgende toewijzingstoestand van systeemelementen 
hebben: 


Toewijzing Aanvraag Beschikbaar 


ABC ABC ABC 
pe i pad 000 000 
pı 200 202 
p 302 000 
punt 100 
p 002 002 


We beweren dat het systeem niet in een impassesituatie verkeert. Inderdaad vin- 
den we, als we ons algoritme hierop loslaten, dat de volgorde <po, p2, p3, pi, pa > 
tot gevolg heeft dat Klaar[i] = true voor alle i. 

Stel dat proces p2 nog een aanvraag doet voor een exemplaar van type C. 
De Aanvraag-matrix wordt als volgt gewijzigd. 


Aanvraag 

ABC 
Po 000 
Pi 202 
p2 001 
P3 100 


p4 002 
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We beweren dat het systeem zich nu in een impasse bevindt. Hoewel we de 
systeemelementen die door proces po worden vastgehouden kunnen terugvor- 
deren, is het aantal beschikbare systeemelementen niet voldoende om aan de 
aanvragen van de andere processen te kunnen voldoen. Dus zitten de processen 
P1, p2, P3 en pa in een impasse. 


8.5.2 Eén exemplaar van elk systeemelement-type 


Evenals het algoritme om impasses te vermijden is het algoritme voor het opspo- 
ren van impasses van de orde m X n?. Als alle systeemelementen slechts één 
enkel exemplaar hebben, kunnen we een sneller algoritme definiëren. Opnieuw 
zullen we een variant van de graaf voor het toewijzen van systeemelementen ge- 
bruiken; deze noemen we een wacht-graaf. Deze graaf wordt uit de graaf voor 
het toewijzen van systeemelementen verkregen door de knooppunten van de syst- 
eemelement-typen te verwijderen en de bijbehorende pijlen in elkaar over te laten 
gaan. 

Preciezer uitgedrukt, een pijl van p; naar p; in een wacht-graaf houdt in dat 
proces pi erop wacht dat proces pj een systeemelement vrijgeeft dat p; nodig heeft. 
Dan en alleen dan komt er een pijl (p:,p;) in de wacht-graaf voor, als de bijbeho- 
rende graaf voor het toewijzen van systeemelementen twee pijlen (p;,s4) en (Sapi) 
voor een systeemelement s, bevat. Bijvoorbeeld, in figuur 8.9 laten we een graaf 
zien voor het toewijzen van systeemelementen (a) en de bijbehorende wacht-graaf 
(b). 

Zoals eerder het geval was, bestaat er dan en alleen dan een impasse in het 
systeem indien de wacht-graaf een lus bevat. Om impasses op te sporen is het 
nodig dat het systeem de wacht-graaf bijhoudt en periodiek een algoritme aanroept 
dat kijkt of er een lus in de graaf voorkomt. 

Een algoritme voor het ontdekken van een lus in een graaf vereist een aantal 
bewerkingen in de orde van n?, waarin n het aantal knooppunten in de graaf is. 
Hoewel dit minder kost dan het algemene algoritme voor het opsporen van een 
impasse, is er een aanzienlijke overhead gemoeid met het opsporen van zulke 
lussen. 


8.5.3 Het gebruik van het opsporingsalgoritme 


Wanneer moeten we het algoritme aanroepen? Het antwoord hangt af van twee 
factoren: | 


@ Hoe vaak zal naar verwachting een impasse optreden? 
@ Hoeveel processen zullen, wanneer er een impasse optreedt, daarvan hinder 
ondervinden? 
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(b) 


Figuur 8.9 
(a) Graaf voor het toewijzen van systeemelementen met (b) de bijbehorende wacht-graaf 


Als impasses dikwijls voorkomen, moet het opsporingsalgoritme vaker wor- 
den aangeroepen. Systeemelementen die aan processen die in een impasse zitten 
zijn toegewezen, zullen werkeloos zijn tot de impasse kan worden doorbroken. 
Bovendien kan er een groeiend aantal processen in de impasselus vast komen te 
zitten. 

Impasses kunnen alleen ontstaan wanneer een proces een aanvraag doet die 
niet onmiddellijk gehonoreerd kan worden. Het is mogelijk dat deze aanvraag de 
aanvraag is die de keten van wachtende processen sluit. In het uiterste geval 
zouden we het algoritme voor het opsporen van impasses iedere keer dat aan een 
aanvraag niet onmiddellijk kan worden voldaan kunnen aanroepen. In dit geval 
kunnen we behalve de groep processen die in een impasse zit ook het proces 
identificeren dat de impasse ’veroorzaakte’. (In werkelijkheid is elk van de in een 
impasse zittende processen een schakel in de lus in de graaf voor het toewijzen 
van systeemelementen; dus hebben ze allemaal samen de impasse veroorzaakt.) 
Als er veel verschillende systeemelement-typen zijn, kan één aanvraag veel ver- 
schillende lussen in de toewijzingsgraaf veroorzaken, waarbij iedere lus werd vol- 
tooid door de meest recente aanvraag en werd ‘veroorzaakt’ door dat ene identifi- 
ceerbare proces. 

Natuurlijk zou het bij elke aanvraag aanroepen van het algoritme voor het 
opsporen van impasses een aanzienlijke overhead in verwerkingstijd betekenen. 
Een goedkoper alternatief zou bestaan in het gewoon wat minder veelvuldig aan- 
roepen van het algoritme, bijvoorbeeld ieder uur, of telkens wanneer de CVE- 
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gebruiksfactor beneden de 40 procent zakt. (Een impasse verknoeit uiteindelijk 
de doorvoer in het systeem en zal de CVE-gebruiksfactor doen dalen.) Als het 
opsporingsalgoritme op willekeurige tijdstippen wordt aangeroepen, kunnen er 
veel lussen in de toewijzingsgraaf voorkomen. We zijn in het algemeen niet in 
staat te zeggen welk proces van de vele processen die in een impasse vastzitten 
de impasse veroorzaakte’. 


8.6 Het oplossen van impasses 


Wanneer een opsporingsalgoritme vaststelt dat er een impasse is ingetreden, moet 
het systeem de impasse oplossen. Er zijn twee keuzemogelijkheden voor het door- 
breken van een impasse. Eén oplossing is eenvoudig één of meer processen voor- 
tijdig te beëindigen om het wachten in een kring te doorbreken. De tweede mo- 
gelijkheid is een aantal systeemelementen voortijdig te ontnemen aan één of meer 
van de processen die in de impasse zitten. 


8.6.1 Beëindiging van processen 


Om de impasse op te heffen door het beëindigen van een proces kan men van 
twee methoden gebruik maken. In beide methoden vordert het systeem alle sys- 
teemelementen terug die aan de beëindigde processen waren toegewezen. 


@ Beëindig alle processen die in een impasse zitten. Dit zal zeker de impasselus 
doorbreken, maar de prijs is hoog omdat de verwerking van deze processen al 
geruime tijd aan de gang kan zijn en de resultaten van deze gedeeltelijke ver- 
werking verloren gaan en waarschijnlijk later opnieuw berekend moeten wor- 
den. 

@ Beëindig de processen één voor één tot de impasselus opgeheven is. Deze me- 
thode vereist een aanzienlijke overhead, omdat na het beëindigen van ieder 
proces een algoritme voor het opsporen van een impasse moet worden aange- 
roepen om vast te stellen of er nog steeds processen in een impasse verkeren. 


U ziet dat het beëindigen van een proces misschien niet eens zo gemakkelijk is. 
Als het proces middenin het bijwerken van een bestand zat, zal het voortijdig 
beëindigen van het proces dat bestand in een incorrecte toestand achterlaten. 
Evenzo moet het systeem, als het proces middenin het afdrukken van een regel 
op de printer zat, de printer in de juiste staat terugbrengen voordat het systeem 
verder gaat met het afdrukken van de volgende job. 

Als de methode van gedeeltelijke beëindiging gebruikt wordt moeten we, 
gegeven een stel processen dat zich in een impasse bevindt, bepalen welk proces 
(of welke processen) beëindigd moet(en) worden om te proberen de impasse te 
doorbreken. Dit is een beleidskwestie die lijkt op de problemen bij CVE-werkin- 
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deling. De vraagstelling is fundamenteel een kwestie van economie; we moeten 
die processen beëindigen waarvan de kosten van het afbreken zo laag mogelijk 
zijn. Helaas mist de term ’zo laag mogelijke kosten’ precisie. Er zijn veel factoren 
die bepalen welk proces wordt gekozen, zoals: 


1. De prioriteit van het proces. 

2. Hoe lang is het proces al verwerkt, en hoeveel langer moet het proces nog 
verwerkt worden voordat zijn aangewezen taak voltooid is. 

3. Hoeveel en welke typen systeemelementen heeft het proces gebruikt (bijvoor- 
beeld, is het eenvoudig om de systeemelementen voortijdig te ontnemen?) 

4. Hoeveel systeemelementen heeft het proces nog nodig om gereed te komen. 

5. Hoeveel processen zullen bij terugkeer betrokken zijn. 


8.6.2 Het voortijdig ontnemen van systeemelementen 


Om impasses op te lossen door gebruik te maken van het voortijdig ontnemen 
van systeemelementen, passen we dit achtereenvolgens toe op enige processen en 
geven we deze systeemelementen aan andere processen totdat de impasselus is 
doorbroken. 

Als voortijdig ontnemen vereist is om impasses aan te kunnen, moeten er 
drie kwesties worden bekeken. 


© Het uitkiezen van een slachtoffer. Welke systeemelementen moeten aan welke 
processen voortijdig worden ontnomen? Evenals bij voortijdige beëindiging 
van een proces, moeten we de volgorde van het voortijdig ontnemen bepalen 
om de kosten zo laag mogelijk te houden. 
We keren terug naar ons voorbeeld van het oversteken van een rivier, en 
veronderstellen dat er 1000 stenen in liggen. Neem een impassesituatie waarbij 
twee mensen betrokken zijn, P en Q. 


© Stel dat P een hogere prioriteit heeft dan Q (P kan bijvoorbeeld een politie- 
agent zijn). Dan zal Q achteruit moeten, ongeacht de situatie. | 


O Stel dat P nog slechts twee stenen nodig heeft om de rivier over te steken 
(dat wil zeggen dat P al 998 stenen genomen heeft). In dit geval zou het 
het redelijkste zijn om van Q te verlangen dat hij achteruitgaat. 


O Stel dat P en Q middenin de rivier in een impasse komen. Er is niemand 
achter Q, maar er komen tien mensen achter P aan. In dit geval zou het 
het redelijkste zijn te verlangen dat Q achteruitgaat. Anders moeten er elf 
mensen achteruit. 


@ Terugkeer (Engels: rollback). Als we een systeemelement voortijdig aan een 
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proces ontnemen, wat moet er dan met het proces gebeuren? Het is duidelijk 
dat het niet verder kan gaan met zijn normale uitvoering; het mist een noodza- 
kelijk systeemelement. We moeten het proces naar een veilige toestand terug- 
brengen, en het vanuit die toestand opnieuw starten. Maar wat is een veilige 
toestand en hoe gemakkelijk kan deze worden vastgesteld? 

De eenvoudigste oplossing is een totale terugkeer: beëindig het proces 
en start het dan opnieuw. Het werkt echter effectiever het proces slechts zover 
terug te zetten als nodig is om de impasse te doorbreken. Deze methode vereist 
evenwel dat het systeem meer informatie bijhoudt over de toestand van al de 
processen die draaien. Laten we naar het voorbeeld van het oversteken van de 
rivier teruggaan. Een totale terugkeer is analoog aan het geval dat we de per- 
soon naar het punt van uitgang laten teruggaan. Zo moet bijvoorbeeld iemand 
uit Amsterdam die een rivier in Frankrijk probeert over te steken naar Amster- 
dam terugkeren. 

Deze situatie is natuurlijk niet economisch. Het is natuurlijker de impas- 
selus te doorbreken door naar één van de oevers van de rivier terug te gaan. 
Een nog effectievere methode is het leggen van diverse extra stenen in de rivier, 
zodat één van de bij de impasse betrokken personen opzij kan stappen om 
de impasse te doorbreken (zie figuur 8.10). In een computersysteem kan een 
controlepunt worden vastgelegd. Een controlepunt is het vastleggen van de 
toestand van het proces om terugkeer mogelijk te maken. 


@ Verhongering. Hoe garanderen we dat er geen verhongering zal optreden? Dat 


wil zeggen, hoe kunnen we garanderen dat systeemelementen niet altijd voor- 
tijdig aan hetzelfde proces zullen worden ontnomen? 


AR : 


Figuur 8.10 
Het toevoegen van stenen om een beperkte vorm van terugzetten (rollback) toe te staan 
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In een systeem waarin het selecteren van een slachtoffer primair op kos- 
tenfactoren berust, kan het gebeuren dat altijd hetzelfde proces als slachtoffer 
wordt gekozen. Het gevolg is dat dit proces nooit zijn aangewezen taak kan 
voltooien. Deze situatie wordt verhongering genoemd, en daarmee moet in elk 
praktisch systeem rekening worden gehouden. Het is duidelijk dat we moeten 
garanderen dat een proces alleen een (klein) aantal malen als slachtoffer kan 
worden uitgekozen. De meest voorkomende oplossing is het aantal malen dat 
het proces werd teruggezet te laten meespelen in de kostenfactor. 


8.7 Gecombineerde aanpak impassebehandeling 


Men heeft het argument naar voren gebracht dat geen van de fundamentele be- 
naderingswijzen voor het behandelen van impasses (dat wil zeggen, het voorkó- 
men, vermijden en opsporen) geschikt is voor de gehele scala van problemen bij 
het toewijzen van systeemelementen in besturingssystemen. Howard [1973] heeft 
voorgesteld deze fundamentele methoden te combineren, waardoor het mogelijk 
wordt dat de optimale aanpak voor ieder type systeemelementen in het systeem 
wordt benut. De voorgestelde methode gaat uit van het idee dat systeemelemen- 
ten kunnen worden onderverdeeld in klassen die hiërarchisch zijn geordend. Er 
wordt een techniek voor het ordenen van systeemelementen (zie paragraaf 8.3.4) 
op de, klassen toegepast. Binnen iedere klasse kan de meest geschikte techniek 
voor het behandelen van impasses worden gebruikt. 

Het is gemakkelijk om te laten zien dat een systeem dat deze strategie ge- 
bruikt vrij is van impasses. Een impasse kan inderdaad niet betrekking hebben 
op meer dan één klasse, omdat de systeemelementen zijn geordend. Dienten- 
gevolge is het systeem impassevrij. 

Deze techniek lichten we toe aan de hand van een systeem dat uit de vier 
hieronder beschreven klassen van systeemelementen bestaat: 


@ Interne systeemelementen. Systeemelementen die door het systeem gebruikt 
worden, zoals een procesbesturingsblok. 

@ Het centrale geheugen. Geheugen dat door een gebruikersjob wordt gebruikt. 

@ Job-systeemelementen. Randapparaten die toewijsbaar zijn (zoals een mag- 
neetbandeenheid) en bestanden. 

@ Verwisselbare ruimte. Ruimte voor iedere gebruikersjob op het externe geheu- 
gen. 


Een ideale gemengde oplossing voor impasses binnen dit systeem ordent de klas- 
sen als aangegeven en gebruikt de volgende benaderingswijzen voor iedere klasse: 


@ Interne systeemelementen. Men kan gebruik maken van voorkómen door het 
ordenen van systeemelementen, daar het kiezen tussen aanvragen waaraan nog 
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niet voldaan is tijdens executie niet nodig is. 

@ Het centrale geheugen. Men kan gebruik maken van voorkómen door het voor- 
tijdig ontnemen van systeemelementen, omdat een job altijd door program- 
maverwisseling uit het geheugen gezet kan worden, en het centrale geheugen 
voortijdig ontnomen kan worden. 

@ Job-systeemelementen. Men kan gebruik maken van vermijding, daar de be- 
nodigde informatie betreffende behoeften aan systeemelementen uit de job- 
besturingskaarten verkregen kan worden. 

@ Verwisselbare ruimte. Men kan gebruik maken van toewijzing vooraf, daar de 
maximumgeheugenbehoeften gewoonlijk bekend zijn. 


Dit voorbeeld laat zien hoe, binnen het kader van het ordenen van systeemele- 
menten, diverse fundamentele methoden kunnen worden gecombineerd om een 
effectieve oplossing voor het impasseprobleem te krijgen. 


8.8 Samenvatting 


Een impassetoestand treedt op wanneer twee of meer processen voor onbepaalde 
tijd wachten op een gebeurtenis die alleen door een van de wachtende processen 
kan worden veroorzaakt. In principe zijn er twee methoden voor het behandelen 
van impasses: 


@ Gebruik een of ander protocol om te garanderen dat het systeem nooit in een 
impassesituatie zal komen. 
@ Laat toe dat het systeem in een impassesituatie geraakt en los deze dan op. 


Een impassesituatie kan dan en alleen dan optreden indien tegelijkertijd 
aan vier voorwaarden in het systeem is voldaan: wederzijdse uitsluiting, bezet- 
houden-en-wachten, het niet voortijdig ontnemen van systeemelementen en het 
wachten-in-een-kring. Om impasses te voorkómen zorgen we ervoor dat ten min- 
ste één van de voorwaarden nooit optreedt. Er zijn fundamenteel drie manieren 
om impasses te voorkómen. 


@ Bezet-houden-en-wachten. Alvorens met zijn uitvoering verder te gaan moet 
elk proces al de systeemelementen die het nodig heeft verkrijgen. 

e Het niet voortijdig ontnemen van systeemelementen. Als het proces enkele sys- 
teemelementen vasthoudt en het vraagt nog een systeemelement aan, en dit 
systeemelement kan niet onmiddellijk aan dat proces worden toegewezen (dat 
wil zeggen dat het proces moet wachten), dan moet het proces al de systeemele- 
menten die het op dat moment vasthoudt vrijgeven. 

@ Het wachten-in-een-kring. Onderwerp alle typen aan een lineair ordeningsche- 
ma. leder proces kan alleen systeemelementen in opklimmende volgorde ver- 
krijgen. 
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Een andere methode voor het vermijden van impasses, die minder strikt 
is dan het bovengenoemde algoritme om impasses te voorkómen, is het laten 
verschaffen van informatie vooraf die weergeeft hoe elk proces de systeemelemen- 
ten zal benutten. Het bankiersalgoritme moet het maximumaantal van de 
systeemelementen per klasse weten dat door elk proces kan worden aangevraagd. 
Met gebruikmaking van deze informatie kan een algoritme ter vermijding van 
impasses worden opgesteld. 

Als een systeem niet van een of ander protocol gebruik maakt om te garan- 
deren dat impasses nooit zullen optreden, moet een methode voor het opsporen 
en oplossen van impasses worden gehanteerd. Een algoritme voor het opsporen 
van impasses moet worden aangeroepen om vast te stellen of er een impasse is 
ontstaan. Wordt een impasse ontdekt, dan moet het systeem de impasse oplossen 
door óf enige van de in een impasse vastzittende processen voortijdig te beëin- 
digen, óf door systeemelementen aan enige van de in een impasse geraakte 
processen voortijdig te ontnemen. 

In een systeem dat slachtoffers voor terugkeer voornamelijk op grond van 
kostenfactoren selecteert kan verhongering optreden. Het gevolg is dat het ge- 
selecteerde proces zijn aangewezen taak nooit volbrengt. 

Tenslotte is het argument naar voren gebracht dat geen van deze fundamen- 
tele methoden op zichzelf geschikt is voor de gehele scala van problemen bij het 
toewijzen van systeemelementen in besturingssystemen. De fundamentele me- 
thoden kunnen worden gecombineerd, waardoor selectie van de optimale metho- 
de mogelijk wordt voor iedere klasse van systeemelementen. 


Opgaven 


8.1 Schrijf verschillende voorbeelden op van impasses die niets met een com- 
putersysteem te maken hebben. 


8.2 Zijn al de noodzakelijke voorwaarden die in paragraaf 8.2.1 werden geïn- 
troduceerd onafhankelijk, of moet aan één (of meer) voorwaarden vol- 
daan zijn wil ook aan een andere voldaan zijn? Zo ja, kunt u dan een 
’minimumstel’ noodzakelijke voorwaarden aangeven. 


8.3 Ontwerp een algoritme voor het oversteken van een rivier zo dat verhon- 
gering en impasses niet mogelijk zijn. 


8.4 Is er een impasse mogelijk waarbij slechts één enkel proces betrokken 
is? 


8.5 De programmatuur kan stuk gaan. Hoe beïnvloedt het uitvallen van een 
randapparaat elk van de drie methoden voor het behandelen van impas- 
ses (voorkómen, vermijden en opsporen)? Welke stappen kunnen wor- 
den ondernomen (zo die nodig zijn) om te proberen verbetering in de 
situatie aan te brengen nadat een randapparaat is uitgevallen? 
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86 Eris wel beweerd dat juiste spool-verwerking impasses zou elimineren. 
En natuurlijk elimineren we hiermee de wedijver tussen kaartlezers, plot- 
ters, printers, enzovoort. Het is zelfs mogelijk spool-verwerking op mag- 
neetbanden toe te passen (wat we trapsgewijze verwerking noemen). Dan 
zouden de systeemelementen CVE-tijd, geheugen en schijfruimte over- 
blijven. Is het mogelijk dat voor deze systeemelementen een impasse op- 
treedt? Zo ja, hoe? Welk impasseschema zou het beste lijken om deze 
impasses (zo die mogelijk zijn) te elimineren, of tegen welke voorwaarde 
wordt gezondigd (indien ze niet mogelijk zijn)? 

8.7 Bewijs dat het veiligheidsalgoritme van paragraaf 8.4 een aantal bewer- 
kingen in de orde van m X n? vereist. 


8.8 Beschouw de verkeersimpasse die afgebeeld is in figuur 8.11. 
a. Toon aan dat aan de vier noodzakelijke voorwaarden voor impasse 
in dit voorbeeld inderdaad voldaan is. 
b. Bedenk een eenvoudige regel om impasses te vermijden. 


8.9 Wat is het belangrijkste verschil tussen impasse en verhongering? 


z 


8 

: 

o 
CE TE fE m8 


Figuur 8.11 
Een impasse in het verkeer 
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8.10 


8.11 


8.12 


8.13 


8.14 
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[Holt 1971] Beschouw een systeem dat uit vier systeemelementen van 
hetzelfde type bestaat die door drie processen gemeenschappelijk wor- 
den gebruikt, waarvan elk hooguit twee systeemelementen nodig heeft. 
Toon aan dat het systeem impassevrij is. 


[Holt 1971] Beschouw een systeem dat uit m systeemelementen van het- 
zelfde type bestaat, die door n processen gemeenschappelijk worden ge- 
bruikt. Toon aan dat het systeem impassevrij is als: 

a. Behoefte: > 0 voor i = 1, 2, … m. 

b. De som van de maximumbehoeften kleiner is dan m+n. 


Stel dat een systeem zich in een onveilige toestand bevindt. Toon aan 
dat het mogelijk is dat de processen hun uitvoering voltooien zonder dat 
ze in een impassesituatie komen. 


In een werkelijk computersysteem zijn noch de beschikbare systeemele- 

menten noch de behoeften van processen aan systeemelementen over 

een lang tijdsbestek (maanden) constant. Systeemelementen gaan stuk of 

worden vervangen , nieuwe processen komen en gaan, nieuwe systeem- 

elementen worden gekocht en aan het systeem toegevoegd. Als impasses 

onder controle worden gehouden met het bankiersalgoritme, welke van 

de volgende veranderingen kunnen dan veilig worden gerealiseerd (zon- 

der de mogelijkheid van impasses te introduceren) en onder welke om- 

standigheden? 

a. Vermeerder Beschikbaar (nieuwe systeemelementen worden toege- 

voegd). 

b. Verminder Beschikbaar (systeemelement wordt permanent uit het 
systeem verwijderd). 

. Vermeerder Max (voor één proces, het kan meer vragen). 

. Verminder Max (een proces besluit dat het niet zoveel nodig heeft). 

. Vermeerder het aantal processen. 

. Verminder het aantal processen. 


mh Oo O&O 


Beschouw een systeem waarop 5000 jobs per maand draaien zonder een 
methode voor het voorkómen of vermijden van impasses. Ongeveer 
tweemaal per maand treden er impasses op; in zo’n situatie moet de 
operateur ongeveer tien jobs per impasse beëindigen en opnieuw draaien. 
Elke job is vijf gulden waard (in CVE-tijd) en de jobs zijn gewoonlijk 
ongeveer half klaar wanneer zij afgebroken worden. 

Een systeemprogrammeur heeft een schatting gemaakt dat een al- 
goritme voor het vermijden van impasses (zoals het bankiersalgoritme) 
bij installatie in het systeem de gemiddelde verwerkingstijd van jobs met 
ongeveer 10% zou doen toenemen. Omdat de machine momenteel 30% 
leeglooptijd heeft, zouden alle 5000 jobs per maand nog steeds gedraaid 
kunnen worden, hoewel de turnaround-tijd gemiddeld 20% omhoog zou 
gaan. 
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8.15 


8.16 


8.17 


a. Wat zijn de argumenten vóór het installeren van het algoritme voor 
het vermijden van impasses? 

b. Wat zijn de argumenten tegen het installeren van het algoritme voor 
het vermijden van impasses? 


Beschouw het volgende beleid voor het toewijzen van systeemelementen. 
Het aanvragen en vrijgeven van systeemelementen is op elk moment toe- 
gestaan. Als aan een aanvraag voor systeemelementen niet kan worden 
voldaan, omdat de systeemelementen niet beschikbaar zijn, controleren 
we alle processen die geblokkeerd zijn omdat ze op systeemelementen 
wachten. Als deze processen de gewenste systeemelementen hebben, 
worden ze van het wachtende proces weggenomen en aan het proces 
met de aanvraag gegeven. De vector van systeemelementen waarop het 
wachtende proces staat te wachten wordt verhoogd met het aantal sys- 
teemelementen dat werd weggenomen. 

Neem bijvoorbeeld een systeem met drie systeemelement-typen en 
de vector Beschikbaar die de beginwaarde (4,2,2) heeft gekregen. Als pro- 
ces A om (2,2,1) verzoekt, krijgt het deze. Als B om (1,0,1) verzoekt, 
krijgt het deze. Als dan A (0,0,1) aanvraagt, wordt A geblokkeerd 
(systeemelement niet beschikbaar). Als C nu (2,0,0) aanvraagt, krijgt het 
het beschikbare element (1,0,0) en het element dat aan A was toegewezen 
(omdat A geblokkeerd is). A’s Toepassing-vector gaat omlaag (1,2,1) en 
zijn Behoefte-vector gaat omhoog (1,0,1). 

a. Kan er een impasse optreden? Zo ja, geef een voorbeeld. Zo niet, aan 
welke noodzakelijke voorwaarde kan niet worden voldaan? 
b. Kan blokkering voor onbepaalde tijd optreden? 


Beschouw de volgende momentopname van een systeem. 


Ti oewijzing Maximum Beschikbaar 


ze D012 0012 1520 
pı 1000 1750 
pi 4354 2356 
ps 0632 0652 
ps 0014 0656 


Beantwoord de volgende vragen met gebruikmaking van het bankiersal- 

goritme: 

a. Wat is de inhoud van de reeks Behoefte? 

b. Is het systeem in een veilige toestand? 

c. Als er een aanvraag van proces pı voor (0,4,2,0) binnenkomt, kan dan 
aan de aanvraag onmiddellijk worden voldaan? 


Wat zijn de moeilijkheden die kunnen ontstaan wanneer een proces moet 
terugkeren als gevolg van een impasse? 


Hoofdstuk 8 Impasses 


8.18 Kan een systeem ontdekken dat sommige processen bezig zijn te verhon- 
geren? Als het antwoord ’ja’ is, leg dan uit hoe. Als het antwoord ’nee’ 
is, verklaar dan hoe het systeem het verhongeringsprobleem kan aanpak- 
ken. 


8.19 Het bankiersalgoritme voor een enkel systeemelement-type kan eenvou- 
dig worden verkregen uit het algemene bankiersalgoritme door het aan- 
tal dimensies van de verschillende reeksen met één te verminderen. Toon 
met een voorbeeld aan dat de bankiersmethode voor meerdere systeem- 
element-typen niet kan worden geïmplementeerd door de methode voor 
het enkelvoudige systeemelement-type individueel op elk systeemele- 
ment-type toe te passen. 


8.20 Stel dat u het veiligheidsalgoritme om impasses te vermijden heeft ge- 
codeerd en nu het algoritme voor het opsporen van impasses wenst te 
implementeren. Kan dit gedaan worden door gewoon het veiligheidsal- 
goritme te gebruiken en opnieuw te definiëren Maximum; = Wachtend; 
+ Toewijzing, waarin Wachtend; een vector is die aangeeft op welke 
systeemelementen proces i staat te wachten, en Toewijzing: wordt gedefi- 
nieerd zoals in paragraaf 8.4? 


8.21 Laat zien hoe de vier algoritmen om impasses te voorkómen kunnen 
worden toegepast op ons probleem van het oversteken van de rivier. 
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geven door Habermann [1969], Holt [1971a, 1972], en Parnas en Habermann 
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gegeven door Fontao [1971]. Een praktische aanpak voor het beheren van sys- 
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[1973]. Een methode om impasses te vermijden waarin de systeemelementen zijn 
onderverdeeld in subsystemen, werd voorgesteld door Lomet [1980]. 
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rekenen is bestudeerd door Devillers [1977], Gold [1978] en Minoura [1982]. De 
kwestie van het testen of een computersysteem impassevrij is werd besproken 
door Kameda [1980]. 
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hoofdstuk 8] en Cofmann en Denning [1973, paragraaf 2.3]. | 


9 


PARALLELLE PROCESSEN 


Tot nu toe hebben we alleen de kwestie van parallellisme (ook: parallelbewerking 
of simultane verwerking; Engels: concurrency) alleen bekeken in relatie tot com- 
ponenten van de apparatuur of gebruikersprocessen. In dit hoofdstuk onderzoe- 
ken we het algemene vraagstuk van parallellisme in relatie tot willekeurige algo- 
ritmen. In het bijzonder houden we ons bezig met parallellisme binnen één enkel 
proces alsook parallellisme als onderdeel van meerdere processen. 


9.1 Voorrangsgrafen 


Beschouw het volgende programmasegment, programma 1, dat een paar eenvou- 
dige rekenkundige bewerkingen verricht. 


a:= xt y; 
b:=z +1; 
c:= a — b; 
w:=c¢c +l; 


Stel dat we een paar van deze opdrachten in parallelbewerking willen uitvoeren. 
In onze processor, of meerdere CVE’s, kunnen we meerdere functionele eenheden 
(zoals opteleenheden) hebben. ’Optellen’ en ’aftrekken’ zouden bewerkingen kun- 
nen zijn die betrekking hebben op matrices of vectoren, of op zeer grote verza- 
melingen (vereniging en doorsnede) of op bestanden (aaneenschakeling en ver- 
schil). Met meerdere CVE’s zouden we een aantal opdrachten simultaan (paral- 
lel) met een aantal andere kunnen verwerken, waarbij we onze totale verwerkings- 
tijd terugbrengen. 

De opdracht c := a — b kan natuurlijk niet worden uitgevoerd voordat 
aan zowel a als b waarden zijn toegekend. Evenzo kan w := c + 1 niet worden 
uitgevoerd voordat de nieuwe waarde van c berekend is. Daar staat tegenover 
dat de opdrachten a := x + yenb:= z + 1 simultaan zouden kunnen worden 
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uitgevoerd omdat geen van beide van de ander afhankelijk is. 

Waar het bij dit voorbeeld om gaat is, dat er binnen een enkel programma 
met betrekking tot de verschillende opdrachten zekere voorrangsbeperkingen gel- 
den. In de volgende paragrafen zullen we deze ideeën formeel behandelen. 


9.1.1 Definitie 


Een voorrangsgraaf is een gerichte acyclische graaf (graaf zonder lussen), waarvan 
de knooppunten overeenkomen met individuele opdrachten. Een pijl van knoop- 
punt O; naar knooppunt O; betekent dat opdracht O; alleen dan kan worden 
uitgevoerd nadat opdracht O; uitgevoerd is. 

Bijvoorbeeld, in de voorrangsgraaf die is afgebeeld in figuur 9.1 gelden de 
volgende voorrangsrelaties: 


@ O2 en O; kunnen worden uitgevoerd nadat O: is uitgevoerd. 

@ Os kan worden uitgevoerd nadat O2 is uitgevoerd. 

@ Os en Os kunnen worden uitgevoerd nadat O4 is uitgevoerd. 

@ 0; kan alleen worden uitgevoerd nadat Os, Os en O3 zijn uitgevoerd. 
Merk op dat Os gelijktijdig met O2, O4, Os en Os kan worden uitgevoerd. 


De voorrangsgraaf mag geen lussen vertonen (moet acyclisch zijn). De graaf 
in figuur 9.2 heeft de volgende voorrangsbeperkingen: O3 kan alleen worden uit- 


Figuur 9.1 
Voorrangsgraaf 
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Figuur 9.2 
Voorrangsgraaf met een lus 


gevoerd nadat O» is uitgevoerd en O2 kan alleen worden uitgevoerd nadat O3 is 
uitgevoerd. Het is duidelijk dat aan deze beperkingen niet tegelijkertijd voldaan 
kan zijn. 


9.1.2 Voorwaarden voor parallellisme 


Wanneer kunnen twee opdrachten in een programma parallel worden verwerkt 
en nog steeds dezelfde resultaten opleveren? Wil dat zeggen dat er een pijl moet 
lopen van O; naar O2 in de voorrangsgraaf die met dit programma correspon- 
deert? Voordat we deze vraag beantwoorden gaan we eerst een notatie afspreken. 


@ L(O;) = ai, a, … Am, de lees-verzameling voor Oi, is de verzameling van alle 
variabelen waarvan de waarden worden gebruikt gedurende de uitvoering van 
opdracht O;. 

@ S(O) = bi, bz, … bn, de schrijf-verzameling voor Oi, is de verzameling van 
alle variabelen waarvan de waarden worden gewijzigd (geschreven) door de 
uitvoering van opdracht Oj. 


Laten we deze notatie toelichten aan de hand van de opdracht c := a — b. De 
waarden van de variabelen a en b worden gebruikt om de nieuwe waarde van c 
te berekenen. Vandaar dat a en b tot de lees-verzameling behoren. De (oude) 
waarde van c wordt in de opdracht niet gebruikt, maar er wordt een nieuwe 
waarde gedefinieerd als gevolg van het uitvoeren van de opdracht. Daarom be- 
hoort c tot de schrijf-verzameling, maar niet tot de lees-verzameling. 


Lc: 
S(c : 


a — b) = {a,b} 
a — b) = {c} 


9.2 Specificatie 


Voor de opdracht w := c + 1 zijn de lees- en schrijf-verzamelingen: 


c} 


Lw: = { 
= {w} 


S(w : 


De doorsnede van L(O;) en S(O;) hoeft niet leeg te zijn. Bijvoorbeeld, voor de 
opdracht x := x + 2 geldt: L(x := x + 2) = S(x:= x + 2) = {x}. j 

Een ander voorbeeld: neem de opdracht lees(a). Let erop dat in a wordt 
gelezen, zodat de waarde ervan verandert. De lees- en schrijf-verzamelingen zijn: 


CFD) 
cT) 


L(lees(a)) = { } 
S(lees(a)) = a 


Aan de volgende drie voorwaarden moet zijn voldaan, willen twee opeen- 
volgende opdrachten O: en O2 parallel kunnen worden uitgevoerd met hetzelfde 
resultaat als wanneer beide opdrachten sequentieel werden uitgevoerd. Deze 
voorwaarden werden het eerst geformuleerd door Bernstein [1966] en zijn nu 
algemeen bekend als de condities van Bernstein. 


1. (Oi) A S(O2) 
2. S(0:) N L(O») 
3. S(O1) A S(O2 


we, FL 
ME 
wad 


We kunnen dit toelichten aan de hand van de opdrachten: Oi: a: = x + yen 
Oz: b: = z + 1. Deze twee opdrachten kunnen parallel worden uitgevoerd, omdat 


LO) = {x,y} 
L(O2) = {z} 
S(O:) = {a} 
S(O2) = {b} 


O2 kan echter niet parallel worden uitgevoerd met O3: c := a — b, omdat 


S(O2) N L(03) = {b}. 


9.2 Specificatie 


De voorrangsgraaf is een nuttig instrument voor het definiëren van voorrangs- 
beperkingen van de delen van een bewerking. Een voorrangsgraaf zou echter 
moeilijk in een programmeertaal gebruikt kunnen worden omdat het een twee- 
dimensionaal iets is. De programmeur heeft andere middelen nodig om de voor- 
rangsrelaties tussen de verschillende opdrachten in een programma te specifice- 
ren. 
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9.2.1 De constructies ’vertak’ en ‘verbind’ 


De begrippen vertak en verbind (Engels: fork respectievelijk join) werden geïntro- 
duceerd door Conway [1963] en Dennis en Van Horn [1966] en behoorden tot 
de eerste taalnotaties voor het specificeren van parallellisme. 

De ’vertak L’-instructie levert twee parallelle bewerkingen in een program- 
ma op. De ene bewerking begint bij de opdracht met de label L, terwijl de andere 
de uitvoering vervolgt met de opdracht die volgt op de vertak-instructie. 

Bekijk, ter illustratie van dit denkbeeld, het volgende programmasegment: 


Oi; 
vertak L; 
Os; 


L: 03; 


Een deel van de voorrangsgraaf die bij dit programma hoort is weergegeven in 
figuur 9.3. Wanneer de ’vertak L’-opdracht wordt uitgevoerd, wordt een nieuwe 
bewerking gestart bij Os. Deze nieuwe bewerking wordt parallel aan de oude 
bewerking uitgevoerd, die zelf verder gaat bij Oo. 

U ziet dat de uitvoering van een vertak-opdracht een enkele bewerking op- 
splitst in twee onafhankelijke bewerkingen; vandaar de naam vertak. 

De verbind-instructie verschaft de middelen om de twee parallelle bewer- 
kingen weer te combineren tot één. Elk van de twee bewerkingen moet verzoeken 
met de andere verbonden te worden. Daar bewerkingen met verschillende snel- 


Figuur 9.3 
Voorrangsgraaf voor de vertak-constructie 
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heid uitgevoerd kunnen worden, is het mogelijk dat de ene bewerking de verbind 
eerder uitvoert dan de andere. In dit geval wordt de bewerking die de verbind het 
eerst uitvoert beëindigd, terwijl de tweede bewerking mag doorgaan. Zouden er 
drie bewerkingen verbonden moeten worden, dan worden de eerste twee die de 
verbind uitvoeren beëindigd, terwijl de derde mag doorgaan. 

We moeten weten hoeveel bewerkingen verbonden moeten worden, zodat 
we ze allemaal behalve de laatste kunnen beëindigen. De verbind-instructie heeft 
een parameter om het aantal bewerkingen aan te geven die verbonden moeten 
worden. Dus heeft de uitvoering van de verbind-instructie met een parameter 
aantal het volgende effect: 


aantal := aantal — 1; 
if aantal > 0 then quit; 


waarin aantal een niet-negatieve gehele variabele is, en quit een instructie die de 
beéindiging van de uitvoering tot gevolg heeft. Voor twee bewerkingen zou de 
variabele aantal de beginwaarde 2 krijgen. 

De verbind-instructie moet atomisch worden uitgevoerd; dat wil zeggen dat 
de parallelle uitvoering van twee verbind-instructies gelijk staat met het achter- 
eenvolgend uitvoeren van deze twee opdrachten, in een willekeurige volgorde. 
Het belang van deze opdracht zal in paragraaf 9.5 worden gedemonstreerd. 

Bezie, ter illustratie van dit denkbeeld, het volgende programmasegment: 


aantal := 2; 
vertak L/; 


O1; 
go to L2; 

L1: O2; 

L2: verbind aanta}; 
O3; 


Een gedeelte van de voorrangsgraaf die met dit programma correspondeert is 
weergegeven in figuur 9.4. 

U ziet dat de uitvoering van de verbind-instructie verschillende parallelle 
bewerkingen samenvoegt; vandaar de naam verbind. 

Laten we deze ideeën met nog een paar voorbeelden verder toelichten. Ga 
nog eens even terug naar programma | uit het begin van dit hoofdstuk (zie para- 
graaf 9.1). Om de parallelle bewerking van de eerste twee opdrachten mogelijk 
te maken zou het programma herschreven kunnen worden, waarbij we dan van 
de vertak- en verbind-instructies gebruik maken: 


Hoofdstuk 9 Parallelle processen 


Ver- 
bind 


Figuur 9.4 
Voorrangsgraaf voor de verbind-constructie 


aantal := 2; 


vertak Ll; 
a:= xt y; 
go to L2; 
Li:b:=z + 1; 
L2: verbind aantal; 
c:= a — b; 
w:= c + |; 


We keren nu terug naar de voorrangsgraaf van figuur 9.1. Het daarmee 
corresponderende programma dat gebruik maakt van de vertak- en verbind-in- 
structies is: 


go to L3; 

L2: O¢ 
go to L3; 

L1: O3; 

L3: verbind aantal; 
O7; 


Let erop dat in figuur 9.1 slechts één verbind-knooppunt O7 voorkomt, dat 
een verbindingsniveau 3 heeft. Daarom is er slechts één verbind-opdracht nodig. 
De teller (aantal) voor deze verbind krijgt de beginwaarde 3. 

Als laatste voorbeeld nemen we een programma dat van een sequentieel 
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bestand f kopieert naar een ander bestand g. Door van een dubbele buffer, r en 
s, gebruik te maken, kan dit programma simultaan lezen van fen schrijven naar 


g. 


var f, g; file of T; 
EEN 
aantal: integer; 
begin 
reset(f); 
lees(f,r); 
while not eof{f) 
do begin 
aantal := 2; 
Si=7; 
vertak L1; 
schrijfig,s); 
go to L2; 
LI: lees(f,r); 
L2: verbind aantal; 
end; 
schrijfig,r); 


end. 


De vertak- en verbind-instructies zijn een krachtig middel voor het schrijven 
van parallelle programma’s. Helaas hebben programma’s die deze opdrachten 
gebruiken een lastige besturingsstructuur. De vertak-instructie lijkt op de ’go to’- 
instructie wat het effect betreft dat deze heeft op het punt van uitvoering. Er is 
al veel gezegd over de ongewenste effecten van de ’go to’-opdracht. In plaats van 
dit te herhalen verwijzen we de geïnteresseerde lezer naar het artikel van Dijkstra 
[1968a]. 


9.2.2 De parallel-opdracht 


Een constructie in een hogere programmeertaal voor het specificeren van paral- 
lellisme is de parbegin/parend-opdracht van Dijkstra [1965a], die de volgende 
vorm heeft: 


parbegin O1; O2; ...; On parend; 


Elke O; is één enkele opdracht. Alle opdrachten binnen de parbegin en parend 
kunnen parallel worden uitgevoerd. Zo is de voorrangsgraaf die correspondeert 
met de bovenstaande opdracht afgebeeld in figuur 9.5, waarin Oo en On+1 de 
opdrachten voorstellen die respectievelijk net vóór de parbegin- en net na de parend- 
opdracht komen. Merk op dat opdracht O,+1 alleen kan worden uitgevoerd nadat 
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Figuur 9.5 
Voorrangsgraaf voor de parallel-opdracht 


alle opdrachten O;, voor i = 1, 2, ..., n zijn uitgevoerd. 

Laten we ter illustratie van deze begrippen nog enkele voorbeelden geven. 
Kijk opnieuw naar programma 1. Om de parallelle bewerking van de eerste twee 
opdrachten mogelijk te maken zou dit met gebruikmaking van de parbegin/ 
parend-constructie als volgt herschreven kunnen worden: 


We kunnen het volgende programma schrijven dat overeenkomt met de 
voorrangsgraaf in figuur 9.1: 


Os; 

parbegin 
O3; 
begin 
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Tenslotte herschrijven we het programma dat een bestand f naar een ander 
bestand g kopieert, waarbij we gebruik maken van de parallel-opdracht. 


var f, g; file of T; 
eer a: 
begin 
reset(f); 
lees(f,r); 
while not eof(/) 
do begin 
S:= f; 
parbegin 
schrijfig,s); 
lees(f,r); 
parend; 
end; 
schrijfig,r); 


end 


De parallel-opdracht is gemakkelijk toe te voegen aan een moderne hogere 
programmertaal met blokstructuur en vertoont veel van de voordelen die andere 
gestructureerde besturingsopdrachten hebben. 


Figuur 9.6 


Voorrangsgraaf zonder bijbehorende parallel-opdracht 
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9.2.3 Vergelijking 


Is de parallel-opdracht krachtig genoeg om als model te dienen voor alle mogelij- 
ke voorangsgrafen? Het antwoord is helaas: nee! Laten we, ter illustratie van dit 
punt, eens aannemen dat we de graaf in figuur 9.1 wijzigen door er een pijl aan 
toe te voegen die loopt van knooppunt O; naar Os (zie figuur 9.6). U ziet dat we 
de pijl van Os naar O hebben weggelaten, omdat de toevoeging van een pijl van 
O; naar Os deze overbodig maakte. We beweren, zonder het bewijs te leveren, 
dat bij deze nieuwe graaf geen programma hoort dat alleen de parallel-opdracht 
gebruikt. Probeer maar eens een gelijkwaardig programma te construeren met 
gebruikmaking van parbegin en parend. 

Voor het modelleren van voorrangsgrafen is de vertak/ verbind-constructie 
krachtiger dan de parallel-opdracht. De voorrangsgraaf van figuur 9.6, waarvoor 
geen bijbehorend programma geschreven kan worden dat de parallel-opdracht 
gebruikt, komt overeen met het onderstaande programma dat gebruik maakt van 
de vertak/verbind-constructie. 


Oi; 
aantall := 2; 
vertak L1; 


L1: Ox 

L2: verbind aantall,; 
Os; 

L3: verbind aantal2; 
O7; 


Hoewel de parallel-opdracht alleen niet genoeg is om alle voorrangsgrafen 
te implementeren, kunnen andere mechanismen (zoals de semaforen van para- 
graaf 9.6) aan de parallel-opdracht worden toegevoegd om de kracht van voor- 
rangsgrafen te evenaren. Bovendien verwachten we niet dat alle mogelijke voor- 
rangsgrafen implementatie nodig hebben, maar alleen die welke overeenkomen 
met problemen die in de praktijk echt vóórkomen. Het is niet zonder meer waar 
dat de parallel-opdracht onvoldoende is voor alle problemen uit de praktijk. 


9.3 Herziening van het begrip ’proces’ 


In de vorige paragraaf hebben we voorrangsgrafen geïntroduceerd en hebben we 
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laten zien hoe parallellisme binnen één programma kan worden weergegeven. In 
deze paragraaf formaliseren we het begrip parallelbewerking door opnieuw het 
begrip ’sequentieel proces’ te introduceren. Het begrip ’proces’ werd uitvoeriger 
geïntroduceerd in hoofdstuk 4. 

Niet-formeel uitgedrukt, is een sequentieel proces een programma in uitvoe- 
ring. We leggen er de nadruk op dat een programma op zichzelf geen proces is; 
een programma is een passief iets, terwijl een proces een actief iets is. De uitvoe- 
ring van een proces moet voortgang vinden op sequentiële wijze (vandaar de 
naam sequentieel proces). Dat wil zeggen dat op elk willekeurig tijdstip hoogstens 
één instructie ten behoeve van het proces wordt uitgevoerd. Dus worden twee 
processen, hoewel met hetzelfde programma twee processen annex kunnen zijn, 
toch als twee afzonderlijke bewerkingsreeksen beschouwd. De betrekking tussen 
het begrip ’proces’ en het begrip ’voorrangsgraaf’ zal in paragraaf 9.3.2 onder- 
zocht worden. 


9.3.1 Toestand van een proces 
Een sequentieel proces kan in één van de volgende vier toestanden zijn: 


@ In uitvoering. Instructies worden uitgevoerd. 

@ Geblokkeerd. Het proces wacht op het optreden van een gebeurtenis (zoals het 
gereedkomen van I/O). 

e Gereed voor uitvoering. Het proces wacht erop dat het aan een processor wordt 
toegewezen. 

@ In een impassesituatie. Het proces wacht op een gebeurtenis die nooit zal op- 
treden. 


Het toestandsdiagram dat met deze vier toestanden correspondeert is weer- 
gegeven in figuur 9.7. Het is in wezen hetzelfde als het toestandsdiagram uit 
figuur 4.7, zij het dat de impassetoestand eraan toegevoegd is. 


9.3.2 Verband met voorrangsgrafen 


We hebben gezien dat van parallelbewerking binnen één programma een model 
kan worden gevormd met behulp van een voorrangsgraaf. We hebben ook twee 
verschillende specificatie-notaties gegeven (vertak/verbind en parbegin/parend) 
om een parallelbewerking te beschrijven. Daar we geinteresseerd zijn in het be- 
Schrijven van zo’n bewerking als een groep sequentiéle processen, moeten we 
nu deze twee begrippen: processen en voorrangsgrafen, met elkaar in verband 
brengen. 

Gemakshalve kunnen we elk knooppunt in een voorrangsgraaf opvatten als 
een sequentieel proces. In zo’n omgeving zien we tijdens het leven van één enkel 


Hoofdstuk 9 Parallelle processen 


programma in uitvoering processen dynamisch verschijnen en weer verdwijnen. 
Deze opzet kan evenwel een aanzienlijke overhead tot gevolg hebben, gezien het 
aantal processen dat moet worden gecreëerd en weer tenietgedaan. De overhead 
zou kunnen worden geminimaliseerd als we die activiteiten die sequentieel kun- 
nen worden uitgevoerd tot één proces samenvoegen. Deze wijziging moet echter 
met zorg plaatsvinden, zodat we niet de hoeveelheid parallellisme die in een be- 
werking is toegestaan verminderen. In de voorrangsgraaf van figuur 9.1 bijvoor- 
beeld zouden de opdrachten O2 en O4 tot één enkel proces kunnen worden sa- 
mengevoegd. 

Laten we nu formeel het effect van Dijkstra’s parallel-opdrachten en de 
vertak/verbind-instructies beschrijven, voorzover deze verband houden met 
sequentiële processen. Om onze bespreking te vereenvoudigen beschouwen we 
alleen de vertak/verbind-constructie. We kunnen altijd de parallel-opdracht 
simuleren door van de vertak/verbind-constructie als volgt gebruik te maken. 
Laat 

parbegin O1; O2; …; On parend; 


een algemene opdracht zijn. Deze kan worden gesimuleerd door: 


aantal := n; 
vertak L2; 
vertak L3; 


vertak Ln; 

Os; 

go to Lj; 
L2: Os; 

go to Lj; 
L3: O3; 

go to Lj; 


Ln: On; 
Lj: verbind aantal; 


Wanneer proces P; de opdracht vertak L uitvoert, wordt een nieuw proces 
P; gecreéerd. P; en P; delen hetzelfde programma alsook alle globale variabelen. 
(Het moet duidelijk zijn dat in zo’n omgeving programma’s geschreven moeten 
worden als herbetreedbare code.) Het belangrijkste verschil tussen P; en Pj; is dat 
de instructieteller van P; op L gezet wordt en dat zijn interne apparatuurregisters 
de juiste beginwaarden krijgen. 
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in uitvoering 


geblokkeerd 


gereed voor 
uitvoering 


in een impasse 


Figuur 9.7 
Toestandsdiagram van een proces 


Bij het tegenkomen van de verbind-instructie wordt de waarde van aantal 
met één verminderd. Als het resultaat gelijk aan nul is, gaat het proces door met 
zijn uitvoering. Anders wordt het proces beëindigd. 


9.4 Hiërarchie van processen 


In deze paragraaf verleggen we onze aandacht naar de volgende kwesties: hoe 
staan de verschillende processen met elkaar in verband en welke procesbewerkin- 
gen kunnen worden aangeroepen? Het is handig om een nieuwe grafische weer- 
gave van een bewerking te definiëren, die we een proces-graaf zullen noemen. 

Een proces-graaf is een gerichte boom met een wortel, waarvan de knoop- 
punten overeenkomen met processen. Een pijl van knooppunt P; naar P; betekent 
dat P; P; heeft voortgebracht. In dit geval zullen we zeggen dat P; de ouder van 
P; is, of dat P; het kind is van P;. De graaf moet een boom met een wortel zijn, 
omdat elk proces ten hoogste één ouder kan hebben, maar evenveel kinderen als 
daaruit zijn voortgekomen (zie figuur 9.8). 

Let op het verschil tussen een proces-graaf (die het ontstaan van processen 
afbeeldt) en een voorrangsgraaf (die een voorrangsbetrekking weergeeft). In een 
proces-graaf houdt een pijl van P; naar P}; niet in dat P; alleen na P; uitgevoerd 
kan worden; alleen dat P; uit P; is ontstaan. P; en P; kunnen parallel worden 
uitgevoerd. 
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Figuur 9.8 
Proces-graaf 


9.4.1 Procesbewerkingen 


Nu het begrip proces-graaf uiteengezet is, kunnen we bespreken hoe ouder /kind- 
betrekkingen worden gevormd en de belangrijkste verschillen die er bestaan tus- 
sen een ouder- en een kind-proces. _ 


Het ontstaan van een proces 


Wanneer een proces een nieuw proces (of processen) voortbrengt, door een be- 
werking zoals vertak, bestaan er diverse implementaties: 


1. Uitvoering. Parallel versus sequentieel. 


a. De ouder gaat door met zijn uitvoering parallel met die van zijn kinderen. 
b. De ouder wacht tot al zijn kinderen zijn beëindigd. 


2. Gemeenschappelijk gebruik. Alles versus gedeeltelijk. 


a. De ouder en de kinderen gebruiken alle variabelen gemeenschappelijk. 
b. De kinderen maken alleen gemeenschappelijk gebruik van een deelver- 
zameling van de variabelen van hun ouder. 


Laten we nu in het kort wat meer zeggen over elk van deze mogelijkheden. 
Optie la wordt toegepast in de vertak/verbind-constructie. Wanneer proces 
P; ’vertak L’ uitvoert, wordt een nieuw proces P} in het leven geroepen, waarbij 
P; dus de ouder is van P;. Beide processen worden verder parallel uitgevoerd. 
Optie 1b wordt toegepast in de parallel-opdrachten. Wanneer proces P; de 
opdracht 
parbegin O1; O2; ...; On parend; 
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uitvoert, worden n nieuwe processen voortgebracht, die alle parallel worden uit- 
gevoerd. Proces P; moet echter wachten tot al deze processen beëindigd zijn. Dan 
gaat proces P; met zijn uitvoering verder bij de opdracht die volgt op de parallel- 
opdracht. 

Optie 2a wordt toegepast in zowel de vertak/verbind-constructie als de 
parallel-opdracht. In beide ontwerpen maken de ouder en de kinderen gemeen- 
schappelijk gebruik van alle variabelen. 

Optie 2b wordt toegepast in Unix [Ritchie en Thompson 1974]. Wanneer 
proces P; een nieuw proces P; voortbrengt, heeft dit proces een geheugenbeeld 
dat onafhankelijk is van dat van P;, met inbegrip van toegangspermissie tot alle 
geopende bestanden van P;. Echter, de variabelen waartoe P; toegang heeft zijn 
niet toegankelijk voor P;, omdat P; en P; onafhankelijke geheugenbeelden heb- 
ben. Op deze wijze kunnen P; en P; in Unix alleen met elkaar communiceren 
door het gebruik van gemeenschappelijke bestanden. 

In het algemeen zal een proces zekere systeemfaciliteiten nodig hebben 
(CVE-tijd, geheugen, bestanden, randapparatuur) om zijn taak uit te voeren. 
Wanneer een proces een subproces creëert, kan het subproces in staat gesteld 
worden zijn systeemfaciliteiten rechtstreeks van het besturingssysteem te krijgen, 
of het kan beperkt zijn tot een deelverzameling van de systeemfaciliteiten van 
het ouder-proces. Het is mogelijk dat de ouder zijn systeemfaciliteiten onder zijn 
kinderen moet verdelen, of dat de ouder met verschillende kinderen gemeen- 
schappelijk gebruik maakt van een aantal systeemfaciliteiten (zoals geheugen of 
bestanden). Het opleggen van beperkingen aan een kind-proces, zodat het slechts 
een deel van de systeemfaciliteiten van de ouder gebruikt, voorkomt dat een pro- 
ces het systeem te zwaar belast door te veel subprocessen uit te broeden. 


Het beëindigen van processen 

Een proces wordt beëindigd wanneer het klaar is met het uitvoeren van zijn laat- 
ste opdracht. Er zijn echter nog andere omstandigheden waaronder beëindiging 
plaatsvindt. Een proces kan de beëindiging van een ander proces veroorzaken 
door het commando te geven: 


dood naam; 


waarin naam de naam is van het proces dat beëindigd moet worden. De dood- 
bewerking kan gewoonlijk alleen worden aangeroepen door de ouder van het 
proces dat moet worden beëindigd. Let erop dat een ouder de identiteit van zijn 
kinderen moet weten. Dus wanneer een proces een nieuw proces creëert, wordt 
de identiteit van het nieuwe proces aan de ouder doorgegeven. Bijvoorbeeld, 


naam := vertak L 


creëert een nieuw proces (dat zijn uitvoering bij L begint) waarvan de identiteit 
wordt opgeslagen in de variabele naam. 
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Een ouder kan de uitvoering van één van zijn kinderen om diverse redenen 
beëindigen, zoals: 


a. Het kind heeft het gebruik van enkele systeemfaciliteiten die het toegewezen 
had gekregen overschreden. 
b. De taak die aan het kind was toegewezen is niet langer nodig. 


Om (a) vast te stellen moet er een mechanisme beschikbaar zijn met behulp waar- 
van de ouder de toestand van zijn kinderen kan controleren. 

Veel systemen staan niet toe dat een kind bestaat wanneer zijn ouder beëin- 
digd is. In zulke systemen moeten, als proces P; beëindigd wordt (hetzij normaal 
hetzij voortijdig), al zijn kinderen ook worden beëindigd. Dit verschijnsel wordt 
aangeduid als de cascadebeëindiging, die gewoonlijk op gang wordt gebracht door 
het besturingssysteem. 


9.4.2 Statische en dynamische processen 


Een proces dat niet beëindigd wordt terwijl het besturingssysteem zijn werk doet, 
wordt statisch genoemd; een proces dat beëindigd kan worden wordt dynamisch 
genoemd. Als een systeem alleen uit een beperkt aantal statische processen be- 
staat, is de bijbehorende proces-graaf ook statisch; dat wil zeggen dat deze nooit 
verandert. We moeten natuurlijk voorzichtig te werk gaan wanneer we onze ter- 
men definiëren, aangezien om te beginnen de graaf geen knooppunten heeft. La- 
ten we, in plaats van ons over dit technische detail zorgen te maken, afspreken 
dat we met een statische proces-graaf een proces-graaf bedoelen die na een zekere 
korte’ aanlooptijd een statische toestand bereikt. 

Wat zijn de belangrijkste voor- en nadelen van elk van deze beide benade- 
ringswijzen? Het verschil tussen de twee opzetten lijkt in veel opzichten op ver- 
schillen tussen talen met een blokstructuur (zoals ALGOL, PL/I of Pascal) en 
talen met een statische geheugentoewijzing (zoals FORTRAN). In de eerste 
groep verschijnen en verdwijnen blokken/ processen dynamisch, terwijl in de laat- 
ste blokken/ processen vastgesteld worden bij hun declaratie. De dynamische op- 
zet is flexibeler dan de statische, maar er is meer overhead mee gemoeid, aange- 
zien het ontstaan en beëindigen van processen heel duur kan zijn. 


9.5 Het kritieke-sectieprobleem 


In de vorige paragraaf hebben we een model ontwikkeld van een systeem dat 
uit een aantal met elkaar samenwerkende sequentiële processen bestaat, die alle 
synchroon worden uitgevoerd met gemeenschappelijk gebruik van enkele gege- 
vens. Laten we ter illustratie van dit model een eenvoudig voorbeeld geven dat 
karakteristiek is voor besturingssystemen. 
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In besturingssystemen hebben we vaak te maken met producent/con- 
sument-processen. Een producent-proces produceert informatie die wordt af ge- 
nomen door een consument-proces. Bijvoorbeeld, het stuurprogramma voor een 
printer produceert tekens die worden afgenomen door de printer. Een compileer- 
programma kan assembleercode produceren, die wordt afgenomen door een as- 
sembleerprogramma. Het assembleerprogramma kan op zijn beurt laadmodules 
produceren die worden afgenomen door het laadprogramma. 

Om producent- en consument-processen parallel te kunnen laten draaien 
moeten we een bufferpot opzetten, zodat de buffers kunnen worden gevuld door 
de producent en geleegd door de consument. Een producent kan in de ene buffer 
produceren, terwijl de consument afneemt uit een andere buffer. De producent 
en de consument moeten worden gesynchroniseerd, zodat de consument geen 
‘artikelen’ probeert af te nemen die nog niet geproduceerd zijn. In deze situatie 
moet de consument wachten tot het gevraagde artikel is geproduceerd. 

Het probleem van de producent-consument met onbegrensde buffercapaciteit 
stelt geen beperking aan het aantal buffers. De consument kan op nieuwe artike- 
len moeten wachten, maar de producent kan altijd nieuwe artikelen produceren; 
er zijn altijd lege buffers. Het probleem van de producent-consument met be- 
grensde buffercapaciteit gaat ervan uit dat er een vast aantal, n, buffers is. In dit 
geval moet de consument wachten als al de buffers leeg zijn en de producent 
moet wachten als alle buffers vol zijn. 

In de nu volgende oplossing voor het probleem van de producent-con- 
sument met begrensde buffercapaciteit is de gezamenlijke bufferpot geïmplemen- 
teerd als een rondlopende reeks, met twee logische wijzers, in en uit. De variabele 
in wijst naar de volgende vrije buffer, terwijl uit naar de eerste volle buffer wijst. 
De pot is leeg wanneer in = uit; de pot is vol wanneer in+1 mod n = uit. 

De skip is een doe-niets-instructie. Dus while conditie do skip test gewoon 
herhaaldelijk de conditie tot deze niet-waar (false) wordt. 


type artikel = … ; 
var buffer: array[0..n—1] of artikel: 
in, uit: 0..n—1; 
volgendep, volgendec: artikel; 


in := 0; 
uit := 0; 
parbegin 


producent: begin 
repeat 


produceer een artikel in volgendep 


while in +1 mod n = uit do skip; 
buffer[in] := volgendep; 
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in:= in + 1 mod n; 
until false; 
end; 


consument: begin 
repeat 
while in = uit do skip; 
volgendec := buffer\uit); 
uit := uit + 1 mod n; 


neem het artikel in volgendec af 


until false; 
end; 


parend; 


Dit algoritme zorgt ervoor dat er ten hoogste n—1 buffers tegelijk vol zijn. 
Stel dat we het algoritme zouden willen wijzigen om dit gebrek op te heffen. Een 
mogelijkheid is een ’integer’ variabele teller toe te voegen, die de beginwaarde 0 
krijgt. Teller wordt iedere keer dat een buffer aan de pot wordt toegevoegd opge- 
hoogd, en iedere keer dat we één van de volle buffers uit de pot weghalen wordt 
teller verlaagd. De code voor het producent-proces kan als volgt worden ge- 
wijzigd: 

| repeat 


produceer een artikel in volgendep 


while teller = n do skip; 

buffer{in| : = volgendep; 

in:= in + 1 modn; 

teller := teller + 1; 
until false; | 


De code voor het consument-proces kan als volgt worden gewijzigd: 


repeat | 
while teller = 0 do skip; 
volgendec := buffer{uit); 
uit := uit + 1 mod n; 
teller := teller — 1; 


neem het artikel af in volgendec 


until false; 
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Hoewel zowel de producent- als de consument-routine elk afzonderlijk cor- 
rect zijn, hoeven ze niet correct te functioneren wanneer ze parallel worden uitge- 
voerd. Om dit te illustreren nemen we eens aan dat de waarde van de variabele 
teller op dit moment 5 is en dat de producent- en consument-routines de opdrach- 
ten ‘teller := teller + 1’ en ‘teller := teller — 1’ parallel uitvoeren. Na de uitvoe- 
ring van deze twee opdrachten kan de waarde van de variabele teller 4, 5 of 6 
zijn! Het enige juiste resultaat is teller = 5, wat correct wordt geproduceerd als 
de producent- en consument-routines afzonderlijk worden uitgevoerd. 

We kunnen als volgt aantonen dat teller incorrect kan zijn. Merk op dat de 
opdracht ‘teller := teller + 1’ in de machinetaal geïmplementeerd is als: 


register; := teller; 
register, := register: + 1; 
teller := register); 


waarin register: een lokaal CVE-register is. Op soortgelijke wijze is de opdracht 
‘teller := teller — 1’ geïmplementeerd als: 


registers := teller; 
register, := register, — 1; 
teller := registers; 


waarin register weer een lokaal CVE-register is. Denk eraan dat hoewel register: 
en register, hetzelfde fysieke register kunnen zijn, de inhoud van dit register opge- 
slagen en opnieuw geladen wordt door de routines voor CVE-werkindeling: de 
routine voor het afhandelen van onderbrekingen en het verdeelprogramma (zie 
paragraaf 4.2.3). 

De gelijktijdige uitvoering van de opdrachten ‘teller := teller — 1’ en’ teller 
:= teller + l’ is gelijkwaardig met een sequentiële uitvoering waarin de boven- 
staande opdrachten op het lagere niveau in een of andere willekeurige volgorde 
worden samengevoegd (maar de volgorde van elke opdracht op het hogere niveau 
wordt gehandhaafd). Zo’n mogelijke samenvoeging is (execute = voer uit): 


To: producent execute register: : = teller (register: = 5} 
Tı: producent execute register: := register: + 1 (register: = 6} 
T2: consument execute registers := teller (register, = 5} 


Ts: consument execute register: := register, — | (register, = 4} 
Ts: producent execute teller := register; {teller = 6} 
Ts: consument execute teller := registers {teller 


Il 
A 
=~ 


Let erop dat we de incorrecte toestand ‘teller = 4’ hebben bereikt, waarmee we 
vastleggen dat er vier volle buffers zijn wanneer er in feite vijf volle buffers zijn. 
Als we de volgorde van de opdrachten bij T4 en Ts omkeren, zouden we de incor- 
recte toestand ‘teller = © krijgen. 
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Deze incorrecte toestand kunnen we krijgen omdat we toestonden dat beide 
processen de variabele teller simultaan bewerken. (Merk op dat het simultaan 
uitvoeren van deze twee opdrachten in strijd is met de condities van Bernstein.) 
Om deze moeilijkheid op te lossen moeten we garanderen dat slechts één proces 
tegelijk de variabele teller mag bewerken. Deze constatering leidt ons tot het 
kritieke-sectieprobleem. 


9.5.1 Probleemdefinitie 


Beschouw een systeem van n samenwerkende sequentiële processen (P1, P2, …, 
P,,). Elk proces heeft een codesegment, een kritieke sectie genoemd, waarin het 
proces gemeenschappelijke variabelen kan lezen, een tabel bijwerken, een be- 
stand wegschrijven, enzovoort. Het belangrijke kenmerk van het systeem is dat 
wanneer één proces aan zijn uitvoering in de kritieke sectie bezig is, geen ander 
proces toestemming mag krijgen in zijn kritieke sectie aan zijn uitvoering bezig 
te zijn. Aldus vertoont het uitvoeren van kritieke secties door de processen weder- 
zijdse uitsluiting in de tijd. Het probleem met betrekking tot de kritieke sectie is 
een protocol te ontwerpen dat de processen kunnen gebruiken om met elkaar 
samen te werken. Elk proces moet toestemming vragen om zijn kritieke sectie in 
te gaan. Het codegedeelte dat de implementatie verzorgt van dit verzoek is de 
ingangssectie. De kritieke sectie kan gevolgd worden door een uitgangssectie. De 
overblijvende code is de rest-sectie. 

Een oplossing voor het probleem van de wederzijdse uitsluiting moet vol- 
doen aan de volgende drie voorwaarden: 


a. Wederzijdse uitsluiting. Als proces P; bezig is aan zijn uitvoering binnen zijn 
kritieke sectie, kan geen enkel ander proces binnen zijn kritieke sectie aan zijn 
uitvoering bezig zijn. 


b. Voortgang. Als er geen proces in uitvoering is in zijn kritieke sectie en er 
bestaat een proces dat zijn kritieke sectie wil binnenkomen, dan kunnen alleen 
die processen die niet aan hun uitvoering binnen de rest-sectie bezig zijn in 
aanmerking komen om nu de kritieke sectie binnen te mogen gaan, en de keus 
kan niet voor onbepaalde tijd worden uitgesteld. 


c. Gelimiteerd wachten. Er moet een grens worden gesteld aan het aantal malen 
dat andere processen toestemming krijgen hun kritieke secties binnen te gaan 
nadat een proces een verzoek heeft gedaan zijn kritieke sectie in te gaan, voor- 
dat dit verzoek wordt toegestaan. 


Er wordt van uitgegaan dat elk proces wordt uitgevoerd met een snelheid die 
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niet gelijk aan nul is. Er kan echter geen veronderstelling worden gemaakt met 
betrekking tot de relatieve snelheid van de n processen. 

In paragrafen 9.5.2 en 9.5.3 werken we toe naar oplossingen voor het 
kritieke-sectieprobleem die aan de drie bovenstaande voorwaarden voldoen en 
die niet uitgaan van welke aannamen dan ook betreffende de apparatuurinstruc- 
ties of het aantal processoren dat door de apparatuur wordt ondersteund. Er 
wordt echter van de veronderstelling uitgegaan dat de basisinstructies van de 
machinetaal (de primitieve instructies zoals laad, berg op en test) atomisch wor- 
den uitgevoerd. Dat wil zeggen, als twee instructies parellel worden uitgevoerd is 
het resultaat hetzelfde als wanneer ze in een of andere onbekende volgorde se- 
quentieel worden uitgevoerd. Dus, als een opberg- en laadinstructie parallel wor- 
den uitgevoerd zal de laadinstructie óf de oude óf de nieuwe waarde krijgen, maar 
niet een combinatie van beide. 

In paragraaf 9.5.4 geven we enkele eenvoudige apparatuurinstructies die op 
vele systemen beschikbaar zijn en laten we zien hoe deze doeltreffend kunnen 
worden benut voor het oplossen van het kritieke-sectieprobleem. 


9.5.2 Oplossingen in de programmatuur voor twee processen 


In deze paragraaf gaan we de aanvankelijke pogingen na om algoritmen te ont- 
wikkelen voor het garanderen van wederzijdse uitsluiting. We vestigen onze aan- 
dacht alleen op algoritmen die op slechts twee processen tegelijk van toepassing 
zijn. In paragraaf 9.5.3 behandelen we het algemenere probleem van n processen. 
De processen worden genummerd Po en Pi, waarbij de algemene structuur van 
het probleem is: 


begin 
declaraties van gemeenschappelijke variabelen; 
parbegin 
Po; 
Fi: 
parend; 
end. 


Kortheidshalve definiéren we, wanneer we het algoritme geven, alleen de gemeen- 
schappelijke variabelen en beschrijven we het proces P;. Voor het gemak gebrui- 
ken we P; om het andere proces aan te geven, dat wil zeggen: j = 1 — i. 

De algemene structuur van proces P; wordt hieronder gegeven. De ingangs- 
sectie en de uitgangssectie zijn door een rechthoekje omsloten om de belangrijke 
codesegmenten te benadrukken. 
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repeat 


ingangssectie; 


kritieke sectie 


uitgangssectie; 


rest-sectie 


until false; 


Algoritme 1 | 
Onze eerste benadering is dat we de processen een gemeenschappelijke variabele 
beurt laten gebruiken die de beginwaarde 0 (of 1) krijgt. Als beurt = i, dan krijgt 
proces P; toestemming tot uitvoering binnen zijn kritieke sectie. 


repeat 


while beurt # i do skip; 


kritieke sectie 


beurt := j; 


rest-sectie 
until false; 


Deze oplossing garandeert dat slechts één proces tegelijk zich binnen zijn kritieke 
sectie kan bevinden. Hij voldoet echter niet aan de eis van voortgang, omdat deze 
eis inhoudt dat de processen elkaar strikt afwisselen in de uitvoering van de 
kritieke sectie. Bijvoorbeeld, als beurt = 0 en Pı wil zijn kritieke sectie binnen- 
gaan, kan het dit niet doen, zelfs al kan Po zich in de rest-sectie bevinden. 


Algoritme 2 

Het probleem met algoritme 1 is dat het niet de toestand van elk proces onthoudt, 
maar zich alleen herinnert welk proces zijn kritieke sectie mag binnengaan. Om 
dit probleem te verhelpen kunnen we de variabele beurt vervangen door de vol- 
gende reeks (array): 
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var vlag: array[0..1] of boolean; 
De elementen van de reeks krijgen de beginwaarde false. Als vilag{i] de waarde 
true heeft, dan is proces P; bezig met zijn uitvoering in de kritieke sectie. 


De algemene structuur van proces P; zou zijn: 


repeat 


while viag{j] do skip; 


vlagli] : = true; 


kritieke sectie 


vlag{i] : = false; 


rest-sectie 
until false; 


Hier gaan we eerst na of het andere proces in zijn kritieke sectie is (vlag{j] = 
true). Is dat zo, dan wachten we. Dan zetten we onze viag{i] op true en gaan we 
onze kritieke sectie binnen. Wanneer we onze kritieke sectie uitgaan zetten we 
onze vlag terug op false, waardoor nu het andere proces zijn kritieke sectie mag 
ingaan als het stond te wachten. 

Dit algoritme garandeert niet dat slechts één proces tegelijk aan zijn uitvoe- 
ring bezig is in zijn kritieke sectie. Beschouw bijvoorbeeld de onderstaande volg- 
orde in de bewerking: 


To: Po gaat de while-opdracht in en ziet dat vlag{l]} = false. 
Ti: Pı gaat de while-opdracht in en ziet dat viag{0] = false. 
Ta: Pı zet vlag{1] op true en gaat de kritieke sectie in. 
Ts: Pozet vlag[0] op true en gaat de kritieke sectie in. 


Nu hebben we een toestand bereikt waarin Po en P; allebei in hun kritieke sectie 
zijn, hetgeen in strijd is met de eis van de wederzijdse uitsluiting. 

Dit algoritme is wezenlijk afhankelijk van de exacte timing van de twee 
processen. De bovenstaande volgorde zou afkomstig kunnen zijn van een omge- 
ving waarin verschillende processoren tegelijkertijd in uitvoering zijn, of waarin 
een onderbreking (zoals door het tijdregister) is opgetreden onmiddellijk nadat 
stap To werd uitgevoerd (en nog een onderbreking na 72), en de CVE van het ene 
proces naar het andere wordt overgeschakeld. 
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Algoritme 3 

Het probleem met algoritme 2 is dat proces P; een beslissing aangaande de toe- 
stand van P; nam voordat P; de gelegenheid had de toestand van de variabele 
vlag{j] te veranderen. We kunnen proberen dit probleem te corrigeren. Evenals 
in algoritme 2 handhaven we de array vlag. Ditmaal evenwel geeft het zetten van 
vlag{i} = true alleen aan dat P; de kritieke sectie wil ingaan. 


repeat 


vlag{i} := true; 


while vlag{j] do skip; 


kritieke sectie 


vlag{i] : = false; 


rest-sectie 
until false; 


Dus in dit algoritme zetten we eerst onze vlag[i] op true, om aan te geven dat we 
onze kritieke sectie willen ingaan. Dan controleren we of een ander proces niet 
ook zijn kritieke sectie wil ingaan. Als dat zo is wachten we. Dan gaan we onze 
kritieke sectie in. Wanneer we de kritieke sectie uitgaan, zetten we onze vlag op 
false, aldus het andere proces (als het staat te wachten) de gelegenheid gevend 
zijn kritieke sectie in te gaan. 

In deze oplossing is, ongelijk aan algoritme 2, voldaan aan de eis van weder- 
zijdse uitsluiting. Helaas wordt niet voldaan aan de eis van voortgang. Ter illus- 
tratie van dit probleem beschouwen we de volgende bewerkingsvolgorde. 


To: Pozet vlag{0] = true. 
Ti: Pi zet vlag{l] = true. 


Nu zitten Po en Pı voorgoed in een lus in hun respectievelijke while-opdrachten. 


Algoritme 4 

Op dit punt aangekomen is de lezer waarschijnlijk ervan overtuigd dat er geen 
simpele oplossing voor het kritieke-sectieprobleem is. Het lijkt erop dat steeds 
wanneer we het ene probleem in een oplossing verhelpen er weer een ander pro- 
bleem zich voordoet. We geven nu evenwel (eindelijk) een correcte oplossing, die 
te danken is aan Peterson [1981]. Deze oplossing is fundamenteel een combinatie 
van algoritme 3 en een lichte modificatie van algoritme 1. 
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De processen hebben twee variabelen gemeenschappelijk: 


var vlag: array[0..1] of boolean; 
beurt: 0..1; 


In het begin is vlag[0] = vlag{l] = false en de waarde van beurt doet er niet toe 
(maar is óf 0 óf 1). De structuur van proces P; is: 


repeat 


vlagli} := true; 
beurt := j; 
while (v/ag{j] and beurt = j) do skip; 


kritieke sectie 


vlagļi] := false; 


rest-sectie 
until false; 


Om onze kritieke sectie binnen te gaan zetten we eerst onze vlag{i] op true en 
verklaren dat het de beurt is van het andere proces om desgewenst binnen te 
gaan (beurt = j). Als beide processen tegelijkertijd proberen binnen te gaan, zal 
beurt op ongeveer dezelfde tijd zowel op i als op j gezet worden. Slechts één van 
deze toekenningen zal duurzaam zijn; de andere zal plaatsvinden maar onmiddel- 
lijk worden overschreven. De uiteindelijke waarde van beurt beslist welk van de 
twee processen zijn kritieke sectie het eerst mag binnengaan. 

We bewijzen nu dat de oplossing van Peterson correct is. Om dat te doen 
moeten we aantonen dat (a) wederzijdse uitsluiting nog van toepassing is, (b) aan 
de eis van voortgang is voldaan, en (c) de conditie van het gelimiteerd wachten 
is vervuld. 

Om eigenschap (a) te bewijzen merken we op dat elk proces P; alleen zijn 
kritieke sectie ingaat als óf viag{j] = false óf beurt = i. Merk ook op dat, als 
beide processen tegelijkertijd in hun kritieke secties aan hun uitvoering bezig 
zouden kunnen zijn, dan vlag[0] = viag{1] = true. Deze twee constateringen hou- 
den in dat Po en Pi niet met succes hun while-opdracht ongeveer op hetzelfde 
moment zouden kunnen hebben uitgevoerd, aangezien de waarde van beurt alleen 
0 of 1 kan zijn, maar niet beide. Daarom moet één van de processen, zeg P;, de 
while-opdracht met succes hebben uitgevoerd, terwijl P; minstens nog één extra 
opdracht *beurt = j’ uit moest voeren. Aangezien echter op dit moment vlag{j] = 
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true, en beurt = i, en deze conditie zolang zal duren als P; in zijn kritieke sectie 
is, volgt hieruit dat wederzijdse uitsluiting nog steeds geldt. 

Om de eigenschappen (b) en (c) te bewijzen merken we op dat een proces 
P; alleen kan worden verhinderd de kritieke sectie in te gaan als het wordt tegen- 
gehouden in de while-lus door de voorwaarde viag{j] = true en beurt = j; dit is 
de enige lus. Als P; geen interesse heeft voor het ingaan in de kritieke sectie, dan 
is vlag{j] = false en kan P; zijn kritieke sectie ingaan. Als P; vlag{j] op true heeft 
gezet en ook in de while-opdracht bezig is, dan is Of beurt = i Of beurt = j. Als 
beurt = i zal P; de kritieke sectie ingaan. Als beurt = j zal P; de kritieke sectie 
ingaan. Echter, zodra Pj; zijn kritieke sectie verlaat zal hij v/ag{j] terugzetten op 
false, zodat P; zijn kritieke sectie mag ingaan. Als P; vlagļ{j] op true moet zetten, 
moet hij ook beurt = i maken. Dus, omdat P; de waarde van de variabele beurt 
niet verandert terwijl hij in de while-opdracht bezig is, zal P; de kritieke sectie 
ingaan (voortgang) na ten hoogste één doorgang van P; (gelimiteerd wachten). 


9.5.3 Oplossingen in de programmatuur voor N processen 


We hebben gezien dat de oplossing van Peterson het kritieke-sectieprobleem 
oplost voor twee processen. Laten we nu een algoritme ontwikkelen voor het 
oplossen van het kritieke-sectieprobleem voor n processen. Algoritme 5 staat op 
naam van Eisenberg en McGuire [1972], terwijl Algoritme 6 te danken is aan 
Lamport [1974]. 


Algoritme 5 
De gemeenschappelijke gegevensstructuren zijn: 


var vlag: array[0..n—1] of (loos,wil-in,in-ks); 
beurt: 0..n—1; 


Alle elementen van vlag hebben de beginwaarde loos; het doet er niet toe welke 
beginwaarde (variërend van 0 tot en met n—1) beurt heeft. 
De structuur van proces P; is: 
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var 7:0..n; 
repeat 


repeat 
vlag{i] : = wil-in; 
j := beurt; 
while j # i 
do if vlag{j] # loos 
then j := beurt 


else j := j+ 1 mod n; 
vlagļ|i] : = in-ks; 
j:= 0; 
while (j<<n) and (j=i or vlag{j} + in-ks) do j := j+1; 
until (7 >n) and (beurt =i or viag{[beurt] = loos); 
beurt := i; 


kritieke sectie 


j := beurt+1 mod n; 
while (v/ag{j] = loos) do j := j+1 mod n; 


beurt := j; 
vlag[i] : = loos; 


rest-sectie 
until false; 


Om te bewijzen dat het algoritme van Eisenberg en McGuire correct is, 
moeten we aantonen dat (a) wederzijdse uitsluiting geldt, (b) aan de eis van voort- 
gang is voldaan en (c) we aan de eis van gelimiteerd-wachten voldoen. 

Om eigenschap (a) te bewijzen merken we op dat elk proces P; zijn kritieke 
sectie alleen ingaat als vlag{j} + in-ks voor alle j + i. Omdat alleen P; vlag{il = 
in-ks kan zetten en daar P; vlag{j] slechts inspecteert wanneer vlagli] = in-ks, 
geldt (a). 

Om eigenschap (b) te bewijzen stellen we vast dat de waarde van beurt 
alleen kan worden gewijzigd wanneer een proces zijn kritieke sectie binnenkomt 
of weer verlaat. Dus zolang geen proces zich in zijn kritieke sectie bevindt of deze 
verlaat, blijft de waarde van beurt ongewijzigd. Het eerste proces in de cyclische 
volgorde (i, i+1, ..., n—1, 0, ..., i-1) dat zich kandidaat meldt voor de kritieke 
sectie zal deze ingaan. 
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Om eigenschap (c) te bewijzen gaan we uit van het feit dat wanneer een 
proces de kritieke sectie verlaat, dit het eerste kandidaat-proces in de cyclische 
volgorde als zijn unieke opvolger moet aanwijzen. Dit geeft de zekerheid dat elk 
proces dat zijn kritieke sectie wil ingaan dit ook binnen n—l beurten zal doen. 


Algoritme 6 
Een andere benaderingswijze werd gegeven door Lamport [1974], die een algorit- 
me aangaf dat het bakkersalgoritme genoemd wordt. Dit algoritme werd ontwik- 
keld voor een gedistribueerde omgeving. Wij willen alleen letten op die aspecten 
van het algoritme die van toepassing zijn op een gecentraliseerde omgeving. 

Het bakkersalgoritme berust op een algoritme voor werkindeling dat veel 
gebruikt wordt in bakkerijen, ijssalons, slagerswinkels en dergelijke. Bij het bin- 
nenkomen van de winkel ontvangt iedere klant een nummer. De klant met het 
laagste nummer is de volgende die geholpen wordt. Helaas kan het bakkersal- 
goritme niet garanderen dat niet twee processen hetzelfde nummer krijgen. In 
dat geval wordt het proces met de laagste naam het eerst geholpen. Dat wil zeg- 
gen, als P; en P; hetzelfde nummer krijgen, en als i < j, dan wordt P; het eerst 
geholpen. Aangezien namen van processen uniek en volledig geordend zijn, is 
ons algoritme geheel deterministisch. 

De gemeenschappelijke gegevensstructuren zijn: 


var kies: array [0..n—1] of boolean; 
nummer: array [0..n—1] of integer; 


Deze gegevensstructuren krijgen de beginwaarden false respectievelijk 0. Voor 
het gemak definiéren we de volgende notatie: 


@ (a,b) < (c,d) alsa < c of alsa = cenb < d. 
@ max(ao, ..., an-1) is het kleinste getal k zo dat k > ai voor i = 0, … n—l. 


De structuur van proces P; is: 


repeat 


kies{i] := true; 

nummer|i] : = max(nummer{0], nummer{]], … nummer{n-1]) + 1; 
kies{i] := false; 

for j := 0 ton-1 


do begin 
while kies{j] do skip; 
while nummer|j] # 0 
and (nummer|j],j) < (nummer{i],i) do skip; 
end; 
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kritieke sectie 


rest-sectie 


until false; 


Om te bewijzen dat het bakkersalgoritme correct is moeten we eerst aanto- 
nen dat als P; zich in zijn kritieke sectie bevindt en Px (k + i) al zijn getal[k] 
heeft gekozen zodat het niet gelijk aan nul is, dan geldt: (getalli},i) < (getal[k],k). 
Het bewijs laten we ter oefening over aan de lezer. 

Op grond van het bovenstaande is nu eenvoudig aan te tonen dat wederzijd- 
se uitsluiting geldt. Neem namelijk het geval dat P; zich in zijn kritieke sectie 
bevindt, terwijl Px probeert zijn kritieke sectie in te gaan. Wanneer Px de tweede 
while-opdracht uitvoert voor j = i, ziet het dat: 


® getallk] # 0, en 
® (getallili) < (getal[k],k). 


Aldus blijft Px in een lus in de while-opdracht totdat P; zijn kritieke sectie verlaat. 
Om aan te tonen dat aan de voorwaarden van voortgang en gelimiteerd 
wachten is voldaan en dat het algoritme eerlijkheid garandeert, is het voldoende 
om op te merken dat de processen hun kritieke sectie ingaan op basis van Wie- 
het-Eerst-Komt-het-Eerst-Maalt (WEKEM). | 


9.5.4 Oplossingen in de apparatuur 


Veel machines hebben speciale instructies in de apparatuur die het mogelijk ma- 
ken dat men de inhoud van een woord onderzoekt en wijzigt, of de inhoud van 
twee woorden verwisselt, binnen één geheugencyclus. Deze speciale instructies 
kunnen worden gebruikt om het kritieke-sectieprobleem op te lossen. Laten we, 
in plaats van één specifieke instructie voor één specifieke machine te bespreken, 
de hoofdbegrippen achter dit type instructies abstraheren door de Test-en-Zet- 
instructie als volgt te definiëren: 


functie Test-en-Zet (var doel: boolean): boolean; 
begin 
Test-en-Zet := doel; 
doel := true; 
end; 
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en de Wissel-instructie als volgt: 


procedure Wissel (var a, b: boolean); 
var hulp: boolean; 


begin 
hulp := a; 
a:= b; 
b := hulp; 
end; 


Het belangrijke punt is dat deze instructies atomisch worden uitgevoerd. Dat 
wil zeggen, binnen één geheugencyclus. Dus als twee Test-en-Zet-instructies (of 
Wissel-instructies) gelijktijdig (elk op een andere CVE) worden uitgevoerd, zullen 
deze in een of andere willekeurige volgorde worden uitgevoerd. 

Als de machine de Test-en-Zet-instructie ondersteunt, kan wederzijdse uit- 
sluiting worden geïmplementeerd door een booleaanse variabele slot te declareren 
die de beginwaarde false krijgt. 


repeat 


while Test-en-Zet(slot) do skip; 


kritieke sectie 


rest-sectie 
until false; 


Als de machine de Wissel-instructie ondersteunt, kan wederzijdse uitslui- 
ting op soortgelijke wijze worden gerealiseerd. Een globale booleaanse variabele 
slot krijgt de beginwaarde false. Elk proces heeft ook een lokale booleaanse varia- 
bele sleutel. 


repeat 


sleutel := true; 
repeat 


Wissel(sleutel,slot); 
until sleutel = false; 
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kritieke sectie 


rest-sectie 
until false; 


De bovenstaande algoritmen voldoen niet aan de voorwaarde van gelimiteerd 
wachten. Om dit tot stand te brengen moeten we extra variabelen gebruiken. 
Hierna geven we een algoritme, te danken aan Burns [1978], dat de Test-en-Zet- 
instructie gebruikt en dat aan alle voorwaarden voor de oplossing van het kri- 
tieke-sectieprobleem voldoet. 

De gemeenschappelijke gegevensstructuren zijn: 


var wacht: array [0..n—1] of boolean; 
slot: boolean 


Deze gegevensstructuren krijgen de beginwaarde false. 
De structuur van proces P; is: 


var j:0..n—1 
sleutel: boolean; 
repeat 


wachii] := true; 
sleutel := true; 


while wacht[i] and sleutel do sleutel := Test-en-Zet(slot); 
wacht{i] : = false; 


kritieke sectie 


j := i+1 mod n; 
while (j ~ i) and (not wacht{j]) do j := j+1 mod n; 
if j = i then slot := false; 

else wacht[j] : = false; 


rest-sectie 


until false; 
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Om te bewijzen dat aan de eis van wederzijdse uitsluiting is voldaan merken 
we op dat proces P; zijn kritieke sectie alleen kan ingaan als óf wacht[i] = false 
óf sleutel = false. Sleutel kan alleen false worden door het uitvoeren van de Test- 
en-Zet. Het eerste proces dat de Test-en-Zet uitvoert ziet dat sleutel = false; alle 
andere processen moeten wachten. Wach({i] kan alleen false worden als een ander 
proces zijn kritieke sectie verlaat; slechts één wacht] wordt op true gezet, waar- 
door de eis tot wederzijdse uitsluiting wordt gehandhaafd. 

Dat aan de voorwaarde van voortgang is voldaan willen we bewijzen door 
op te merken dat de argumenten zoals boven voor wederzijdse uitsluiting aange- 
geven ook hier van toepassing zijn, omdat een proces dat de kritieke sectie verlaat 
óf slot = false óf wacht{j} = false maakt. In beide gevallen krijgt een proces dat 
probeert zijn kritieke sectie binnen te komen de gelegenheid dat te doen. 

Om te bewijzen dat aan de voorwaarde van gelimiteerd wachten is voldaan 
merken we op dat wanneer een proces zijn kritieke sectie verlaat, het de reeks 
wacht controleert in de cyclische volgorde (i+ 1, i+2, … n—1, 0, … i-1). Het 
bestempelt het eerste proces in deze volgorde dat in zijn ingangssectie is 
(wacht|j] = true) als het volgende proces dat zijn kritieke sectie mag ingaan. Elk 
proces dat erop wacht zijn kritieke sectie in te gaan zal dit dus binnen n—1 beur- 
ten doen. 


9.6 Semaforen 


De oplossingen voor het probleem van wederzijdse uitsluiting die we in de laatste 
paragraaf hebben gegeven zijn niet gemakkelijk te generaliseren voor complexere 
problemen. Om deze moeilijkheid het hoofd te bieden werd een nieuw stuk 
synchronisatiegereedschap, een semafoor genoemd, geïntroduceerd door Dijkstra 
[1965a]. Een semafoor S is een variabele bestaande uit een geheel getal dat, afge- 
zien van het toekennen van een beginwaarde, alleen kan worden gewijzigd door 
middel van twee atomische standaardbewerkingen: P en V. De klassieke definities 
van P en V zijn: 


US): S:= S + l; 


Wijzigingen van de gehele waarde van de semafoor in de P- en V-bewerkin- 
gen worden ondeelbaar uitgevoerd. Dat wil zeggen, wanneer het ene proces de 
waarde van de semafoor wijzigt, kan geen ander proces tegelijkertijd de waarde 
van diezelfde semafoor wijzigen. Bovendien moet in het geval van de P(S) het 
testen van de gehele waarde van S (S < 0), en de eventuele wijziging daarvan 
(S := S — 1), zonder onderbreking worden uitgevoerd. We zien in paragraaf 9.6.2 
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hoe deze bewerkingen kunnen worden geimplementeerd, maar laten we eerst eens 
zien hoe semaforen kunnen worden gebruikt. 


9.6.1 Gebruik 


Men kan van semaforen gebruik maken wanneer men te maken heeft met het 
kritieke-sectieprobleem voor n processen. De n processen gebruiken een gemeen- 
schappelijke semafoor, weduit, met beginwaarde 1. Elk proces P; is als volgt geor- 
ganiseerd: 


repeat 


P(weduit); 


kritieke sectie 


V(weduit); 


rest-sectie 
until false; 


Semaforen kunnen ook worden gebruikt bij het oplossen van allerlei 
synchronisatieproblemen. Neem bijvoorbeeld twee processen die parallel worden 
uitgevoerd: Pı met een opdracht Oy, en P2 met een opdracht O». Stel dat we eisen 
dat O2 alleen wordt uitgevoerd nadat O; uitgevoerd is. Deze opzet kan vlot wor- 
den geïmplementeerd door Pı en P2 een gemeenschappelijke semafoor synch te 
laten gebruiken, met beginwaarde 0, en door het tussenvoegen in proces Pı van 
de opdrachten: 


O1; 
V(synch); 


en in proces P2 en van de opdrachten: 


P(synch); 


Os; 


Omdat synch de beginwaarde 0 heeft, zal P2 alleen O2 uitvoeren nadat P, V(synch) 
heeft aangeroepen, wat na O: gebeurt. 

Laten we een complexer voorbeeld geven. Bekijk de voorrangsgraaf uit fi- 
guur 9.6 en het daarmee corresponderende onderstaande programma: 
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var a, b, c, d, e, f, g: semafoor; 
(* beginwaarde van alle semaforen is 0 *) 
begin 
parbegin 
begin O:; V(a); V(b); end; 
begin P(a); O2; O4, Vic); V(d); end; 
begin P(b); O3; V(e); end; 
begin P(c); Os; Vif); end; 
begin P(d); P(e); Os; Vg); end; 
begin P(f); P(g); O7; end; 
parend; 
end; 


U zult zich nog wel herinneren dat we hebben betoogd dat de graaf in 
figuur 9.6 geen bijbehorend programma heeft dat de parallel-opdracht benut. 
Het bovenstaande programma demonstreert evenwel dat, met de toevoeging van 
semaforen, de parallel-opdracht even krachtig is als de vertak/ verbind-construc- 
tie. 


9.6.2 Implementatie 


Het belangrijkste nadeel van de oplossingen voor het probleem van de wederzijd- 
se uitsluiting van paragraaf 9.5, en van de boven gegeven definitie van de se- 
mafoor, is dat hierbij steeds een wachtlus vereist is. Terwijl een proces zich in zijn 
kritieke sectie bevindt, moet elk ander proces voortdurend in een lus blijven han- 
gen in de ingangscode. Dit is duidelijk een probleem in een werkelijk multipro- 
grammeringssysteem waarin één CVE door vele processen gemeenschappelijk 
wordt gebruikt. Wachtlussen verspillen CVE-cycli die een ander proces misschien 
productief zou kunnen gebruiken. 

Om de noodzaak van wachtlussen te elimineren kunnen we de definitie van 
de P- en V-semafoorbewerkingen wijzigen. Wanneer een proces de P-bewerking 
uitvoert en ziet dat de waarde van de semafoor niet positief is, moet het wachten. 
Het proces kan evenwel, in plaats van te ’wachtlussen’, zichzelf blokkeren. De 
blokkeer-bewerking plaatst een proces in een wachttoestand. Het draagt dan de 
besturing over aan de CVE-werkindeler, die een ander proces uit de gereed- 
wachtrij selecteert om te worden uitgevoerd. 

Een proces dat geblokkeerd is en wacht op een semafoor S, moet opnieuw 
gestart worden doordat een ander proces een V-bewerking uitvoert. Het proces 
wordt herstart door een wek-bewerking, die de toestand van het proces omzet 
van ‘geblokkeerd’ naar ’gereed’ en het tevens in de gereed-wachtrij plaatst. (De 
CVE kan al of niet worden overgeschakeld van het lopende proces naar het zo- 
juist in de gereed-toestand gebrachte proces, afhankelijk van het algoritme voor 
CVE-werkindeling.) 
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Om semaforen met gebruikmaking van deze definitie te implementeren de- 
finiéren we een semafoor als een record. 


type semafoor = record 
waarde: integer; 
L: list of proces; 
end; 


Elke semafoor heeft een gehele getalwaarde en een lijst (Engels: list) van proces- 
sen. Wanneer een proces op een semafoor moet wachten, wordt het aan de lijst 
van processen toegevoegd. Een V-bewerking verwijdert een proces uit de lijst van 
wachtende processen en wekt het uit de wachttoestand. 

De semafoorbewerkingen kunnen nu worden gedefinieerd als: 


P(S): S.waarde := S.waarde — 1; 
if S.waarde < 0 
then begin 
voeg dit proces toe aan S.L; 
blokkeer; 
end; 


VS): S.waarde := S.waarde + 1; 
if S.waarde < 0 
then begin 
verwijder een proces P uit S.L; 
wek(P); 
end; 


De blokkeer-bewerking schort de uitvoering van het proces dat de bewerking 
aanroept op. De wek(P)-bewerking hervat de uitvoering van een geblokkeerd pro- 
ces P. Deze twee bewerkingen worden door het besturingssysteem geleverd als 
fundamentele systeemaanroepen. 

Let erop dat, terwijl de klassieke definitie van semaforen met wachtlussen 
zodanig is dat de semafoorwaarde nooit negatief is, deze implementatie wel ne- 
gatieve semafoorwaarden kan hebben. Als de semafoorwaarde negatief is, is de 
grootte ervan gelijk aan het aantal processen dat op die semafoor staat te wach- 
ten. Dit feit is een gevolg van het verwisselen van de volgorde van het verlagen 
van de waarde en de test in de implementatie van de P-bewerking. 

De lijst van processen kan gemakkelijk worden geimplementeerd door een 
schakelveld in elk procesbesturingsblok (PBB). Elke semafoor bevat een gehele 
getalwaarde en een wijzer naar een lijst van PBB’s. De eenvoudigste manier om 
processen aan de lijst toe te voegen en eruit te verwijderen zou Laatst-In-Eerst- 
Uit (een stapel) zijn, maar dit zou verhongering kunnen veroorzaken. Dienten- 
gevolge is het gebruikelijker dat de lijst is geïmplementeerd als een wachtrij, en 
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de semafoor bevat dan zowel kop- als staartwijzers naar de rij. In het algemeen 
echter kan de lijst gebruik maken van iedere strategie voor wachtrijvorming 
(FIFO, LIFO, prioriteit, of een andere strategie). Correct gebruik van semaforen 
hangt niet af van een speciale strategie voor wachtrijvorming voor de semafoor- 
lijsten. 

Het kritieke aspect van semaforen is dat ze atomisch worden uitgevoerd. 
We moeten garanderen dat geen twee processen tezelfdertijd P- en V-bewerkin- 
gen op dezelfde semafoor kunnen uitvoeren. Deze situatie is een kritieke-sectie- 
probleem en kan op twee manieren worden opgelost. 

In een omgeving met één processor kunnen we eenvoudig onderbrekingen 
blokkeren gedurende de tijd dat de P- en V-bewerkingen worden uitgevoerd. 
Deze methode werkt in een uniprocessor-omgeving (met één processor), omdat 
zodra onderbrekingen geblokkeerd zijn instructies van verschillende processen 
niet door elkaar heen gebruikt kunnen worden. 

In een omgeving met meerdere processoren werkt het blokkeren van onder- 
brekingen niet. Instructies van verschillende processen (die op verschillende 
processoren worden uitgevoerd) kunnen dan wel op willekeurige wijze dooreen- 
lopen. Als de apparatuur geen speciale instructies levert, kan men elk van de 
correcte oplossingen met behulp van de programmatuur voor het kritieke-sectie- 
probleem gebruiken (bovenstaande algoritmen 4, 5 of 6), waarbij de kritieke sec- 
ties bestaan uit de P- en V-procedures. 

Het is van belang te erkennen dat we met deze definitie van de P- en V- 
bewerkingen wachtlussen niet geheel hebben geëlimineerd. In plaats daarvan 
hebben we dit alleen beperkt tot de kritieke secties van de P- en V-bewerkingen, 
die heel kort zijn. (Indien juist gecodeerd, hoeven ze niet meer dan tien instructies 
in beslag te nemen.) Aldus is de kritieke sectie bijna leeg en treedt er praktisch 
nooit wachten in een wachtlus op. Treedt er dan eens een wachtlus op, dan is dit 
gedurende een heel korte periode. Een geheel andere situatie doet zich voor bij 
toepassingsprogramma’s waarvan de kritieke secties heel lang (uren) of bijna al- 
tijd bezet zijn. In dit geval zou het wachten in wachtlussen erg inefficiënt zijn. 


9,7 Klassieke problemen bij procescoördinatie 

In deze paragraaf geven we een aantal verschillende synchronisatieproblemen die 
voornamelijk van belang zijn omdat zij model staan voor een grote categorie 
van besturingsproblemen in verband met parallellisme. Deze problemen worden 


gebruikt bij het testen van bijna elke nieuw voorgestelde synchronisatiemethode. 
In onze oplossingen voor synchronisatie maken we gebruik van semaforen. 


9.7.1 Het begrensde-bufferprobleem 


Het begrensde-bufferprobleem werd in paragraaf 9.5 geïntroduceerd en wordt 
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gewoonlijk gebruikt om de kracht van synchronisatiefuncties te illustreren. We 
geven hier een algemene structuur van deze opzet, zonder ons vast te leggen op 
een bepaalde implementatie. We nemen aan dat de pot bestaat uit n buffers, 
waarvan elk een bepaald artikel kan bevatten. De weduit-semafoor zorgt voor 
wederzijdse uitsluiting voor de toegang tot de bufferpot. De semaforen leeg en 
vol tellen het aantal lege, respectievelijk volle, buffers. 


type artikel = ...; 
var buffer = ...; 
vol, leeg, weduit: semafoor; 
volgendep, volgendec: artikel; 


vol := 0; 
leeg := n; 
weduit : = 
parbegin 


producent: repeat 


1; 


produceer een artikel in volgendep 
P(leeg); 
P(weduit); 
voeg volgendep aan buffer toe 
V(weduit); 
Vvol); 

until false; 


consument: repeat 
P(vol); 
P(weduit); 
zet een artikel uit buffer in volgendec 
V(weduit); 
Vileeg); 


neem het artikel in volgendec af 
until false; 


parend; 
end. 


Let op de symmetrie tusssen de producent en de consument. We kunnen deze 
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code interpreteren als het produceren door de producent van volle buffers voor 
de consument, of als het produceren door de consument van lege buffers voor de 
producent. Een gedetailleerder voorbeeld geven we in hoofdstuk 10. 


9.7.2 Het lezers/schrijversprobleem 


Een gegevensobject (zoals een bestand of een record) moet gemeenschappelijk 
gebruikt worden door diverse processen. Het kan zijn dat sommige van deze 
processen het gemeenschappelijke object alleen willen lezen, terwijl andere het 
gemeenschappelijke object willen bijwerken (dat is lezen en schrijven). We maken 
onderscheid tussen deze twee procestypen door die processen die alleen geinteres- 
seerd zijn in lezen lezers en de rest schrijvers te noemen. Het is duidelijk dat als 
twee lezers het gemeenschappelijke gegevensobject tegelijkertijd willen lezen, dit 
geen nadelige effecten zal hebben. Als echter een schrijver en een ander proces 
(hetzij een lezer, hetzij een schrijver) het gemeenschappelijke object tegelijk be- 
naderen, kan er chaos ontstaan. Een dergelijke simultane toegang zou in strijd 
zijn met de condities van Bernstein. 

Om de garantie te geven dat deze moeilijkheden niet de kop opsteken, stel- 
len we de eis dat schrijvers tot het gemeenschappelijke object exclusieve toegang 
hebben. Dit synchronisatieprobleem wordt het lezers/ schrijversprobleem ge- 
noemd. Het werd oorspronkelijk geformuleerd en opgelost door Courtois et al. 
[1971]; sindsdien is het gebruikt om vrijwel elke nieuwe synchronisatiefunctie te 
testen. Het lezers/schrijversprobleem heeft verschillende varianten, die alle met 
prioriteiten werken. De eenvoudigste, het eerste lezers/ schrijversprobleem ge- 
heten, vereist dat men geen lezer laat wachten tenzij een schrijver al toestemming 
heeft verkregen het gemeenschappelijke object te gebruiken. Met andere woor- 
den, geen lezer hoeft te wachten tot andere lezers klaar zijn alleen vanwege het 
feit dat een schrijver staat te wachten. Het tweede lezers/ schrijversprobleem ver- 
eist dat zodra een schrijver gereed is deze dan ook zo spoedig mogelijk schrijft. 
Met andere woorden, als een schrijver staat te wachten om toegang tot het object 
te verkrijgen, mogen geen nieuwe lezers beginnen te lezen. 

We merken op dat een oplossing voor elk van beide problemen verhongering 
tot gevolg kan hebben. In het eerste geval kunnen schrijvers verhongeren; in het 
tweede geval kunnen lezers verhongeren. Om deze reden zijn andere varianten 
van het probleem voorgesteld. In deze paragraaf geven we een oplossing voor 
het eerste lezers/schrijversprobleem. In hoofdstuk 10 geven we een oplossing die 
verhongering vermijdt voor een variant van het tweede lezers/ schrijversprobleem. 

In deze oplossing voor het eerste lezers/ schrijverspobleem maken de lezers- 
processen gebruik van de volgende gemeenschappelijké gegevensstructuren. 


var weduit, schr: semafoor, 
leesaantal: integer; 
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De semaforen weduit en schr krijgen de beginwaarde 1, terwijl leesaantal de begin- 
waarde 0 krijgt. Lezers- zowel als schrijversprocessen hebben de semafoor schr 
gemeen. De semafoor weduit wordt gebruikt om wederzijdse uitsluiting te garan- 
deren wanneer de variable leesaantal wordt bijgewerkt. Leesaantal houdt bij hoe- 
veel processen op elk moment het object aan het lezen zijn. De semafoor schr 
fungeert als een semafoor voor wederzijdse uitsluiting voor de schrijvers. Deze 
wordt ook gebruikt door de eerste/laatste lezer die de kritieke sectie ingaat/ver- 
laat. Hij wordt niet gebruikt door lezers die de kritieke sectie ingaan of verlaten 
terwijl andere lezers in hun kritieke sectie zijn. 
De algemene structuur van een lezer-proces is: 


P(weduit); 
leesaantal := leesaantal + 1; 
if leesaantal = 1 then P(schr); 
V(weduit); 


het lezen vindt plaats 
P(weduit); 

leesaantal := leesaantal — 1; 

if leesaantal = 0 then V(schr); 
V(weduit); 


terwijl de algemene structuur van een schrijver-proces is: 
P(schr); 


het schrijven vindt plaats 


Vischr); 


Merk op dat als een schrijver zich in de kritieke sectie bevindt en n lezers 
staan te wachten, één lezer dan in de wachtrij voor schr gezet wordt, terwijl n—1 
lezers in de wachtrij komen voor weduit. Let er ook op dat wanneer een schrijver 
V(schr) uitvoert, we de uitvoering kunnen hervatten van óf de wachtende lezers 
of één enkele wachtende schrijver. De keuze wordt door de werkindeler bepaald. 


9.7.3 Het probleem van de tafelende filosofen 


Het probleem van de tafelende filosofen werd oorspronkelijk geformuleerd en 
opgelost door Dijkstra [1965a]. Sindsdien is het beschouwd als een klassiek 
synchronisatieprobleem, niet wegens enig praktisch nut, maar omdat het een 
voorbeeld is van een grote categorie besturingsproblemen die verband houden 
met parallellisme. 
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Het probleem kan als volgt worden geformuleerd. Vijf filosofen brengen 
hun leven door met denken en eten. De filosofen gebruiken een gemeenschappe- 
lijke ronde tafel waaromheen vijf stoelen staan, één voor iedere filosoof. In het 
midden van de tafel staat een schaal rijst en de tafel is gedekt met vijf eetstokjes 
(zie figuur 9.9). Wanneer een filosoof aan het denken is heeft hij geen contact 
met zijn collega’s. Van tijd tot tijd krijgt een filosoof trek en probeert hij de twee 
eetstokjes op te pakken die het dichtst bij hem liggen (de eetstokjes tussen hem 
en zijn linker- en rechterbuurman). Een filosoof mag slechts één eetstokje tegelijk 
oppakken. Hij kan natuurlijk geen eetstokje oppakken dat een buurman al vast- 
houdt. Wanneer een eetlustige filosoof zijn beide eetstokjes tegelijk heeft, eet hij 
zonder zijn eetstokjes vrij te geven. Wanneer hij klaar is met eten, legt hij zijn 
beide eetstokjes neer en begint hij weer te denken. 

Een simpele oplossing is dat elk eetstokje wordt gerepresenteerd door een 
semafoor. Een filosoof probeert het eetstokje te pakken door een P-bewerking 
op die semafoor uit te voeren; het eetstokje wordt vrijgegeven door een V-bewer- 
king op de semafoor uit te voeren. Dus het gemeenschappelijke gegeven is: 


var eetstokje: array[0..4] of semafoor; 


waarbij alle elementen van eetstokje de beginwaarde 1 krijgen. De structuur van 
filosoof i kan nu als volgt worden beschreven: 


repeat 
P(eetstokjel il); 
P(eetstokje[i+ 1 mod 5)); 


eet 


V(eetstokjelil); 
V(eetstokje[i+ 1 mod 5)); 


denk 
until false; 


Hoewel deze oplossing garandeert dat geen twee buren tegelijk eten, moet 
hij desondanks worden verworpen wegens de mogelijkheid dat er een impasse 
ontstaat. Stel dat al de vijf filosofen tegelijk trek krijgen en dat ieder zijn linker 
eetstokje oppakt. Alle elementen van eetstokje zijn nu gelijk aan nul. Wanneer 
elke filosoof tracht zijn rechter eetstokje te grijpen, zal iedereen voor altijd moe- 
ten wachten. 

Hieronder staan verschillende mogelijke remedies voor het impassepro- 
bleem vermeld. In plaats van een algoritme voor elk van deze oplossingen te 
geven, laten we een deel daarvan ter oefening over aan de lezer en geven we één 
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Figuur 9.9 
De tafelende filosofen 


oplossing in hoofdstuk 10. 

@ Laat hoogstens vier filosofen tegelijk aan de tafel zitten. 

@ Laat een filosoof alleen zijn eetstokjes oppakken als beide beschikbaar zijn 
(merk op dat dit moet gebeuren in een kritieke sectie). 

@ Maak gebruik van een asymmetrische oplossing. Dat wil zeggen, een filosoof 
met een oneven nummer pakt eerst zijn linker eetstokje op en dan zijn rechter, 
terwijl een filosoof met een even nummer eerst zijn rechter en dan zijn linker 
eetstokje oppakt. 


Tenslotte moet iedere bevredigende oplossing voor het probleem van de tafelende 
filosofen de garantie bieden dat geen van de filosofen van honger omkomt. Een 
oplossing die impassevrij is geeft nog niet de garantie dat er geen verhongering 
mogelijk is. 


9.8 Communicatie tussen processen 


Veel van de problemen die we hebben beschreven, en ook andere, worden voorge- 
steld als synchronisatieproblemen. Maar in groter verband zijn deze problemen 
eenvoudige voorbeelden van het grotere probleem van het toestaan van communi- 
catie tussen processen die wensen samen te werken. In deze paragraaf behandelen 
we het algemene probleem van communicatie tussen processen. In hoofdzaak zijn 
er twee elkaar aanvullende communicatiemethoden: gemeenschappelijk geheu- 
gen en berichtensystemen. 

Systemen die van een gemeenschappelijk geheugen gebruik maken vereisen 
dat communicerende processen gebruik maken van een aantal gemeenschappelij- 
ke variabelen. Van de processen wordt verwacht dat zij informatie uitwisselen 
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door het gebruik van deze gemeenschappelijke variabelen. De begrensde-buffer- 
methode die in paragraaf 9.5 besproken werd zou bijvoorbeeld voor dit doel kun- 
nen worden gebruikt. In een systeem met een gemeenschappelijk geheugen berust 
de verantwoordelijkheid voor het verschaffen van informatie bij de toepassings- 
programmeurs; het besturingssysteem hoeft alleen voor het gemeenschappelijke 
geheugen te zorgen. Het berichtensysteem geeft de processen de mogelijkheid be- 
richten uit te wisselen. In deze opzet berust de verantwoordelijkheid voor het 
leveren van voorzieningen voor de communicatie bij het besturingssysteem zelf. 

Het is duidelijk dat deze twee methoden elkaar wederzijds niet uitsluiten 
en tegelijkertijd binnen eenzelfde besturingssysteem gebruikt zouden kunnen 
worden. In deze paragraaf concentreren we ons voornamelijk op berichtensys- 
temen, omdat het gemeenschappelijk-geheugensysteem fundamenteel toepas- 
singsgericht is. Ook beschouwen we alleen systemen met processen met niet-over- 
lappende logische adresruimten. 

De functie van een berichtensysteem is het mogelijk te maken dat processen 
met elkaar communiceren zonder dat het nodig is dat men zijn toevlucht hoeft te 
nemen tot gemeenschappelijke variabelen. Een communicatievoorziening tussen 
processen levert in feite twee bewerkingen op: zend(bericht) en ontvang(bericht). 

Als de processen P en Q met elkaar willen communiceren, moeten ze be- 
richten naar elkaar zenden en van elkaar ontvangen. Daarvoor moet er een com- 
municatieverbinding of communicatielijn tussen hen bestaan. Deze verbinding kan 
op verschillende manieren worden geimplementeerd. Het gaat ons hier niet om 
de fysieke implementatie van een verbinding (zoals een gemeenschappelijk geheu- 
gen of een hoofdtransmissielijn), maar meer om de kwesties die betrekking heb- 
ben op de logische implementatie, zoals de logische eigenschappen. Enkele van 
de fundamentele implementatiekwesties zijn: 


@ Hoe worden communicatielijnen gevormd? 

@ Kan een communicatielijn verbonden zijn met meer dan twee processen? 

@ Hoeveel communicatielijnen kunnen er tussen elk paar processen zijn? 

@ Wat is de capaciteit van een lijn? Dat wil zeggen, heeft de lijn enige buffer- 
ruimte? Zo ja, hoeveel? 

@ Wat is de grootte van de berichten? Kan de lijn berichten met variabele lengte 
aan, of alleen berichten met een vaste lengte? 

@ Is het een één- of tweerichtingsverbinding? Dat wil zeggen, als er een lijn be- 
staat tussen P en Q, kunnen dan berichten slechts in één richting gaan (zoals 
van P naar Q) of in beide richtingen? 


De definitie van éénrichtingsverkeer moet zorgvuldig worden geformuleerd, 
daar een lijn verbonden kan zijn met meer dan twee processen. Zo zeggen we dat 
een lijn alleen éénrichtingsverkeer kent als elk proces dat met de lijn verbonden 
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is Of kan zenden óf ontvangen, maar niet beide, en met elke lijn ten minste één 
ontvanger-proces verbonden is. 

Bovendien zijn er verschillende methoden voor het logisch implementeren 
van een communicatieverbinding en de zend/ontvang-bewerkingen: 


@ Directe of indirecte communicatie. 

@ Zend naar een proces of naar een brievenbus. 
@ Symmetrische of asymmetrische communicatie. 
@ Automatische of expliciete buffering. 

@ Zend als kopie of zend als verwijzing. 

@ Berichten met vaste of variabele lengte. 


We gaan nu deze typen berichtensystemen verder uitwerken. 


9.8.1 Naamgeving 


In deze paragraaf richten we onze aandacht op de eerste drie kwesties aangaande 
de logische implementatie van een verbinding. De communicatie tussen twee 
processen kan voornamelijk direct of indirect zijn. 


Directe communicatie 

Volgens de regel van de directe communicatie moet elk proces dat een bericht 
wil zenden of ontvangen expliciet de naam van de ontvanger of zender van de 
communicatie opgeven. Volgens deze aanpak zijn de functies zend en ontvang als 
volgt gedefinieerd: 


zend(P, bericht). Zend een bericht aan process P. 
ontvang(Q,bericht). Ontvang een bericht van proces Q. 


Een communicatielijn volgens deze opzet heeft de volgende eigenschappen: 


@ Er wordt automatisch een lijn gelegd tussen ieder paar processen dat wil com- 
municeren. De processen moeten alleen elkaars identiteit weten om te kunnen 
communiceren. 

@ Een lijn is met exact twee processen verbonden. 

@ Tussen ieder paar processen bestaat er exact één lijn. 

@ De lijn kent tweerichtingsverkeer. 


Het producent/consumentprobleem bijvoorbeeld kan volgens deze opzet 
op de volgende manier worden gecodeerd: 
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type artikel = ...; 
var volgendep, volgendec: artikel, 
parbegin 
producent: repeat 
produceer een artikel in volgendep 
zend(consument,volgendep),; 
until false; 


consument: repeat 
ontvang(producent,volgendec); 
neem het artikel in volgendec af 
until false; 
parend; 


Als dit voorbeeld wordt opgevat als een begrensde-buffermethode, is de 
grootte van de buffer gelijk aan de capaciteit van de communicatielijn. Dit wordt 
uitvoeriger besproken in paragraaf 9.8.2. | 

Deze methode vertoont een symmetrie in de adressering; dat wil zeggen, 
zowel de zender als de ontvanger moeten elkaar met name noemen willen zij 
kunnen communiceren. Een variant hiervan gebruikt asymmetrie in de adres- 
sering. Alleen de zender noemt de ontvanger met name; de ontvanger is niet 
verplicht de zender met name te noemen. Volgens deze variant worden de func- 
ties zend en ontvang als volgt gedefinieerd: 


@ zend(P,bericht). Zend een bericht naar proces P. 

© ontvang(naam,bericht). Ontvang een bericht van het geeft niet welk proces; 
naam krijgt de naam van het proces waarmee communicatie heeft plaats ge- 
vonden. 


Het nadeel van beide methoden (symmetrisch en asymmetrisch) is dat de 
proces-definities die daarvan het gevolg zijn slechts een beperkte modulaire op- 
bouw vertonen. Het veranderen van de naam van een proces kan ons ertoe nood- 
zaken alle andere proces-definities te inspecteren. Alle verwijzingen naar de oude 
naam moeten worden gevonden, om deze te wijzigen in de nieuwe naam. Deze 
situatie is niet wenselijk indien de proces-definities afzonderlijk vertaald (gecom- 
pileerd) worden. | 


Indirecte communicatie 
Met indirecte communicatie worden de berichten gezonden naar en ontvangen 
uit brievenbussen (ook poorten genoemd; Engels: ports). Een brievenbus kan ab- 
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stract worden gezien als een voorwerp waarin door processen berichten kunnen 
worden geplaatst en waaruit berichten kunnen worden verwijderd. Iedere brie- 
venbus heeft een unieke naam waaraan deze te onderkennen is. Volgens deze 
opzet kan een proces met een ander proces communiceren door middel van een 
aantal verschillende brievenbussen. Twee processen kunnen alleen communi- 
ceren als zij een gemeenschappelijke brievenbus hebben. De functies zend en 
ontvang zijn als volgt gedefinieerd: 


zend(A bericht). Zend een bericht naar brievenbus A. 
ontvang(A bericht). Ontvang een bericht uit brievenbus A. 


In deze aanpak heeft een communicatielijn de volgende eigenschappen: 


@ Een lijn wordt alleen tussen een paar processen gelegd als deze een gemeen- 
schappelijke brievenbus hebben. 

@ Een lijn kan met meer dan twee processen verbonden zijn. 

@ Tussen elk paar communicerende processen kan een aantal verschillende lijnen 
bestaan, die elk corresponderen met één brievenbus. 

@ De lijn kent óf één- óf tweerichtingsverkeer. 


Stel nu dat de processen Pi, P2 en Ps alle gebruik maken van brievenbus A. 
Proces Pı zendt een bericht naar A, terwijl P2 en P3 elk een ontvang uit A uitvoe- 
ren. Wie zal het bericht dat door Pı werd verzonden ontvangen? Deze vraag kan 
op diverse manieren worden beantwoord: 


@ Laat een lijn met ten hoogste twee processen verbonden zijn. 

@ Laat ten hoogste één proces tegelijk een ontvang-bewerking uitvoeren. 

@ Laat het aan het systeem over om willekeurig te selecteren wie het bericht zal 
ontvangen (dat wil zeggen, óf P2 óf P3, maar niet beide, zal het bericht ontvan- 
gen). Het systeem kan aan de zender meedelen wie het bericht heeft ontvangen. 


Eigendom van brievenbussen 


De eigenaar van een brievenbus kan een proces zijn of het systeem. Als een proces 
de eigenaar van de brievenbus is (dat wil zeggen dat de brievenbus aan het proces 
hangt of er deel van is), maken we onderscheid tussen de eigenaar (die alleen 
berichten via deze brievenbus kan ontvangen) en de gebruiker van de brievenbus 
(die alleen berichten naar de brievenbus kan zenden). Daar iedere brievenbus een 
unieke eigenaar heeft, kan er geen verwarring bestaan over de vraag wie een 
bericht dat naar deze brievenbus is gezonden moet ontvangen. Wanneer een pro- 
ces dat de eigenaar van een brievenbus is wordt beëindigd, verdwijnt de brieven- 
bus. Ieder proces dat vervolgens een bericht naar deze brievenbus zendt moet 
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ervan op de hoogte worden gesteld dat de brievenbus niet langer bestaat (een 
vorm van behandeling van een abnormale situatie). 

Er bestaat een aantal manieren om de eigenaar en gebruikers van een be- 
paalde brievenbus aan te wijzen. Eén mogelijkheid is dat het proces variabelen 
mag declareren van het type brievenbus. Het proces dat een brievenbus declareert 
is de eigenaar ervan. Elk ander proces dat de naam van de brievenbus weet kan 
deze gebruiken. Het is ook mogelijk een brievenbus voor gemeenschappelijk ge- 
bruik te declareren en dan extern de identiteit van de eigenaar te declareren. 

Daarentegen heeft een brievenbus waarvan het systeem de eigenaar is een 
eigen bestaan. De brievenbus is dan onafhankelijk en ‘hangt’ niet aan een bepaald 
proces. Het besturingssysteem levert een mechanisme dat een proces de mogelijk- 
heid geeft om: 


@ Een nieuwe brievenbus te creëren. 
@ Berichten via de brievenbus te zenden en te ontvangen. 
@ Een brievenbus op te heffen. 


Het proces dat een nieuwe brievenbus creëert is per definitie de eigenaar. Aan- 
vankelijk is de eigenaar het enige proces dat via deze brievenbus berichten kan 
ontvangen. Het eigenaarschap en het voorrecht om te mogen ontvangen kunnen 
echter door middel van geschikte systeemaanroepen aan andere processen wor- 
den overgedragen. Deze voorziening zou natuurlijk tot gevolg kunnen hebben 
dat er voor iedere brievenbus meerdere ontvangers zijn. Processen kunnen ook 
gemeenschappelijk gebruik van een brievenbus maken door middel van de mo- 
gelijkheid processen te creëren. Als bijvoorbeeld proces P brievenbus A en daarna 
een nieuw proces Q creëerde, kunnen P en Q gemeenschappelijk gebruik maken 
van brievenbus A. Aangezien alle processen met toegangsrechten tot een brieven- 
bus uiteindelijk beëindigd zullen worden, is het mogelijk dat geen enkel proces 
nog toegangsrecht op de brievenbus heeft. In dit geval moet het besturingssys- 
teem de ruimte die voor de brievenbus in gebruik was terugvorderen. Voor deze 
taak kan een zekere vorm van sanering nodig zijn. 


9.8.2 Buffering 


In deze paragraaf bespreken we nog twee kwesties aangaande de logische imple- 
mentatie van een communicatielijn: de capaciteit ervan en eigenschappen van 
berichten. 


Capaciteit 

Een lijn heeft een zekere capaciteit die het aantal berichten bepaalt dat daarin 
tijdelijk kan verblijven. Deze eigenschap kan worden gezien als een berichten- 
wachtrij die aan de lijn hangt. Fundamenteel zijn er drie manieren waarop zulk 
een wachtrij kan worden geimplementeerd: 
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@ Nul-capaciteit. De maximale lengte van de wachtrij is 0; er kunnen dus geen 
berichten voor de lijn in de rij staan. In dit geval moet de zender wachten tot 
de ontvanger het bericht ontvangt. De twee processen moeten worden ge- 
synchroniseerd wil er berichtenoverdracht plaatsvinden. Deze synchronisatie 
wordt rendez-vous genoemd. 

@ Begrensde capaciteit. De wachtrij heeft een eindige lengte n; er kunnen dus 
maximaal n berichten op de lijn zijn. Als de wachtrij niet vol is wanneer er 
een nieuw bericht verzonden wordt, wordt dit in de wachtrij gezet (hetzij door 
het bericht te kopiëren, hetzij door een wijzer naar het bericht bij te houden) 
en kan de zender zonder te wachten zijn verwerking vervolgen. De lijn heeft 
evenwel een eindige capaciteit. Als de lijn vol is moet de zender een vertraging 
ondergaan tot er ruimte in de wachtrij beschikbaar is. 

@ Onbegrensde capaciteit. De wachtrij heeft in principe een oneindige lengte; 
dus kan elk willekeurig aantal berichten erin wachten. De zender ondervindt. 
nooit vertraging. 


Het geval van de nul-capaciteit wordt soms een berichtensysteem zonder 
buffering genoemd; de andere gevallen verschaffen automatische buffering. 

We merken op dat in de gevallen van niet-nul-capaciteit een proces niet 
weet of een bericht, nadat de zend-bewerking voltooid is, is aangekomen. Als 
deze informatie voor de verwerking van cruciaal belang is, moet de zender expli- 
ciet met de ontvanger communiceren om te weten te komen of deze het bericht 
ontvangen heeft. Stel bijvoorbeeld dat proces P een bericht stuurt naar proces Q 
en alleen met zijn verwerking kan doorgaan nadat het bericht ontvangen is. Pro- 
ces P voert de volgende opdrachten uit: 


zend(Q, bericht); 
ontvang(Q, bericht); 


en proces Q voert uit: 


ontvang(P, bericht); 
zend(P,’bevestiging’); 


Berichten 
Er zijn drie soorten berichten die door een proces kunnen worden verzonden: 


@ Berichten met vaste lengte. 
@ Berichten met variabele lengte. 
@ Berichten van een bepaald type. 


Als alleen berichten met een vaste lengte kunnen worden verzonden, is de imple- 
mentatie heel eenvoudig. Deze beperking maakt de programmeertaak evenwel 
moeilijker. Aan de andere kant vereisen berichten met variabele lengte een com- 
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plexere implementatie, maar het programmeren wordt eenvoudiger. 

Het laatste geval, het verbinden van elke brievenbus met een type, is in feite 
alleen toepasbaar op indirecte communicatie. De berichten die naar en uit een 
bepaalde brievenbus gezonden respectievelijk ontvangen kunnen worden, zijn be- 
perkt tot het aangewezen type. Dit is speciaal geschikt voor brievenbussen die 
gedeclareerd zijn in een programmeertaal die sterk op typen geörienteerd is. Bij- 
voorbeeld zou een brievenbus die n artikelen voor het producent/consument- 
probleem moet bevatten gedeclareerd kunnen worden als: 


m:brievenbus|n] of artikel; 


Speciale gevallen 
Er zijn twee speciale gevallen die niet direct in één van de categorieén die we 
besproken hebben thuis horen. 


@ Het proces dat een bericht zendt hoeft nooit te wachten. Als echter de ontvan- 
ger het bericht nog niet ontvangen heeft voordat het zendende proces nog een 
bericht zendt, gaat het eerste bericht verloren. Deze aanpak is gebaseerd op 
de fysieke implementatie van ’zend een verwijzing’ inplaats van ‘zend een 
kopie’. Het voordeel van deze aanpak is dat grote berichten niet meer dan 
eenmaal gekopieerd hoeven te worden. Het belangrijkste nadeel is dat de pro- 
grammeertaak moeilijker wordt. Processen moeten expliciet gesynchroniseerd 
worden, om te garanderen dat er geen berichten verloren gaan en dat de zender 
en de ontvanger niet beide tegelijkertijd de berichtenbuffer bewerken. 

@ Het proces dat een bericht zendt moet wachten tot het een antwoord ontvangt. 
Deze opzet werd gevolgd in het Thoth-besturingssysteem (Cheriton et al. 
[1979]). Volgens dit systeem hebben berichten een vaste lengte (acht woorden). 
Een proces P dat een bericht zendt wordt geblokkeerd tot het ontvangende 
proces het bericht heeft ontvangen en een antwoord, ook uit acht woorden 
bestaande, heeft teruggestuurd met behulp van de functie antwoord(P,bericht). 
Het antwoordbericht overschrijft de buffer die het oorspronkelijke bericht be- 
vat. Het enige verschil tussen de functies zend en antwoord is dat een zend tot 
gevolg heeft dat het zendende proces wordt geblokkeerd, terwijl de antwoord- 
functie zowel het zendende als het ontvangende proces in de gelegenheid stelt 
onmiddellijk met zijn verwerking verder te gaan. 


9.8.3 Foutcondities 


Een berichtensysteem is in het bijzonder nuttig in een gedistribueerde omgeving, 
waarin processen in verschillende locaties (machines) kunnen voorkomen. In zo’n 
omgeving is de kans dat tijdens de communicatie (en de verwerking) een fout zal 
optreden veel groter dan in een omgeving met één enkele machine. In een omge- 
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ving met één machine worden berichten gewoonlijk geïmplementeerd in het ge- 
meenschappelijke deel van het geheugen. Gaat er iets mis, dan gaat het hele sys- 
teem plat. Echter, in een gedistribueerde omgeving worden berichten gewoonlijk 
door communicatielijnen behandeld en hoeft het optreden van een fout in één’ 
locatie niet noodzakelijk te betekenen dat het hele systeem plat gaat. 

Wanneer, hetzij in een gecentraliseerd hetzij in een gedistribueerd systeem, 
een fout optreedt, moet er foutherstel (behandeling van een foutconditie) plaats- 
vinden. Laten we in het kort sommige van de foutcondities bespreken die een 
systeem in het kader van een berichtensysteem moet behandelen. 


Proces wordt beëindigd 

Een zender óf een ontvanger kan eindigen voordat een bericht is verwerkt. Deze 
situatie laat ons zitten met berichten die nooit zullen worden ontvangen of 
processen die op berichten wachten die nooit zullen worden verzonden. We be- 
zien hier twee gevallen. 


l. Een ontvanger-proces P kan wachten op een bericht van een proces Q dat 
werd beëindigd. Wordt er geen actie ondernomen, dan zal P voor altijd ge- 
blokkeerd blijven. (Merk op dat deze conditie geen impasse volgens de klassie- 
ke definite is, omdat er geen wachten in een kring is.) In dit geval kan het 
systeem óf P beëindigen óf P ervan in kennis stellen dat Q werd beëindigd. 

2. Proces P kan een bericht aan een proces Q zenden dat werd beëindigd. In de 
opzet met automatische buffering kan dit geen kwaad; P gaat gewoon door 
met zijn verwerking. Als P moet weten dat zijn bericht door Q is verwerkt, 
moet het programma expliciet een bevestiging vragen. In het geval zonder 
buffering zal P voor altijd geblokkeerd blijven. Evenals in geval (1) kan het 
systeem ófwel P beëindigen óf P ervan in kennis stellen dat Q beëindigd werd. 


Verloren gegane berichten 

Een bericht van proces P aan proces Q kan ergens in het communicatienetwerk 
verloren gaan, wegens een storing in de apparatuur of in een communicatielijn. 
Er bestaan drie fundamentele methoden voor het behandelen van dit geval. 


1. Het besturingssysteem is verantwoordelijk voor het ontdekken van deze ge- 
beurtenis en voor het opnieuw verzenden van het bericht. 

2. Het verzendende proces is verantwoordelijk voor het ontdekken van deze ge- 
beurtenis en voor het desgewenst opnieuw versturen van het bericht. 

3. Het besturingssysteem is verantwoordelijk voor het ontdekken van deze ge- 
beurtenis; vervolgens stelt het het verzendende proces ervan op de hoogte dat 
het bericht verloren gegaan is. Het verzendende proces kan desgewenst door- 
gaan. 


Het is niet altijd nodig het verloren gaan van berichten te signaleren. De gebrui- 
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ker moet aangeven (dat wil zeggen, het systeem meedelen, of deze eis zelf pro- 
grammeren) dat zo’n signalering moet plaatsvinden. | 

Hoe ontdekken we dat een bericht verloren is gegaan? De meest algemene 
methode is het gebruik maken van een korte pauze (Engels: time-out). Wanneer 
een bericht verstuurd wordt, wordt er altijd een antwoordbericht dat de ontvangst 
van het bericht bevestigt teruggestuurd. Het besturingssysteem of een proces kan 
dan een tijdsinterval opgeven waarbinnen het de ontvangstbevestiging verwacht. 
Verstrijkt deze tijdsperiode voordat de bevestiging aankomt, dan kan het bestu- 
ringssysteem (of proces) aannemen dat het bericht verloren is gegaan. Het is 
evenwel mogelijk dat het bericht niet verloren ging, maar dat de reis door het 
netwerk gewoon wat langer duurde. In dit geval is het mogelijk dat er meerdere 
kopieën van hetzelfde bericht door het netwerk gaan. Er moet een mechanisme 
bestaan om onderscheid te kunnen maken tussen deze verschillende typen berich- 
ten. Dit probleem wordt uitvoeriger in hoofdstuk 13 besproken. 


Verminkte berichten 

Het bericht kan aan zijn eindbestemming worden afgeleverd, maar onderweg 
verminkt zijn (wegens ruis in de communicatiekanalen bijvoorbeeld). Dit geval 
wordt net zo behandeld als het geval van een bericht dat verloren is gegaan. Het 
besturingssysteem zal ofwel het oorspronkelijke bericht opnieuw verzenden, of 
het zal het proces van deze gebeurtenis op de hoogte stellen. Gewoonlijk worden 
controle-totalen (zoals pariteit of cyclische redundantiecontrole) gebruikt om dit 
type fout te ontdekken. ` 


9.8.4 Een voorbeeld: Accent 


Laten we als voorbeeld van een besturingssysteem dat op berichten is gebaseerd 
eens kijken naar het besturingssysteem Accent, ontwikkeld aan de Carnegie- 
Mellon Universiteit [Rashid en Robertson 1981] voor de Perq-computer. De kern 
van het Accent-besturingssysteem ondersteunt het creëren en vernietigen van 
meerdere processen. Ieder proces heeft zijn eigen gepagineerd virtueel geheugen 
met een adresruimte van 32 bits. Geen enkel proces deelt zijn geheugen met een 
ander proces, daar alle communicatie plaatsvindt door middel van berichten. Be- 
richten worden gestuurd naar en ontvangen in brievenbussen, die Accent poorten 
(Engels: ports) noemt. 

Zelfs syteemaanroepen vinden plaats via berichten. Bij het creëren van elk 
proces worden ook twee speciale brievenbussen opgezet: de Kern-brievenbus en 
de Gegevens-brievenbus. Een systeemaanroep vindt plaats door het versturen 
van een bericht naar de Kern-brievenbus; alle door het besturingssysteem terug- 
gestuurde waarden komen als een bericht in de Gegevens-brievenbus en kunnen 
dan door het proces worden ontvangen. Alleen de bewerkingen van de berichten- 
communicatie (zend/ontvang) zijn fundamentele opdrachten. 

De systeemaanroep Wijs-Poort-Toe creëert een nieuwe brievenbus en wijst 
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ruimte toe voor de bijbehorende wachtrij voor berichten. De maximumgrootte 
van de berichten-wachtrij moet worden opgegeven bij het creëren van de brieven- 
bus. Het proces dat de brievenbus creëert is de eigenaar ervan. De eigenaar krijgt 
ook toegang tot de brievenbus voor de ontvangst van berichten. Slechts één pro- 
ces tegelijk kan ofwel eigenaar zijn van een brievenbus of daarin ontvangen, maar 
deze rechten kunnen desgewenst naar andere processen worden gestuurd. 

In het begin heeft een brievenbus een lege berichten-wachtrij. Bij het naar 
de brievenbus sturen van berichten worden deze naar de brievenbus gekopieerd. 
Berichten worden op volgorde van prioriteit in de wachtrij geplaatst. Gewoonlijk 
wordt gebruik gemaakt van twee klassen berichten: normaal en onvoorzien. On- 
voorziene berichten hebben hoge prioriteit; normale berichten hebben lage prio- 
riteit. Berichten met dezelfde prioriteit worden FIFO (Eerst-In-Eerst-Uit) in de 
wachtrij geplaatst, maar berichten met hoge prioriteit worden vóór berichten met 
lage prioriteit geplaatst. 

De berichten zelf bestaan uit een kop met vaste lengte en een gegevens- 
gedeelte met variabele lengte. De kop bevat onder meer de lengte van het gehele 
bericht, zijn klasse (normaal of onvoorzien) en twee brievenbusnamen. Wanneer 
een bericht wordt verstuurd, is één brievenbusnaam de naam van de brievenbus 
waarheen het bericht verstuurd wordt. Gewoonlijk verwacht het proces dat het 
bericht verzendt antwoord; de andere brievenbusnaam wordt doorgegeven aan 
het ontvangende proces, dat deze naam kan gebruiken als een ’retouradres’ waar- 
heen berichten kunnen worden teruggestuurd. 

Het variabele gedeelte van het bericht is een lijst van brokjes gegevens die 
elk een bepaald type hebben. Iedere ingang in de lijst heeft een type, een grootte 
en een waarde. Het type van de elementen in het bericht is belangrijk omdat door 
het besturingssysteem gedefinieerde elementen, zoals het eigendomsrecht of het 
toegangsrecht voor ontvangst, procestoestanden en geheugensegmenten, in be- 
richten kunnen worden verstuurd. 

De zend- en ontvangbewerkingen zelf zijn heel flexibel. Wanneer een be- 
richt naar een brievenbus wordt verstuurd, kan de brievenbus vol zijn. Als de 
brievenbus niet vol is, wordt het bericht naar de brievenbus gekopieerd en gaat 
het zendende proces verder. Als de brievenbus vol is, heeft het proces vier moge- 
lijkheden: 

1. Wacht voor onbepaalde tijd tot er ruimte in de brievenbus vrijkomt. 

2. Wacht hoogstens n milliseconden. 3 

3. Wacht in het geheel niet, maar ga onmiddellijk terug. 

4. Eén bericht kan aan het besturingssysteem worden gegeven, dat dit dan vast- 
houdt, zelfs al is de brievenbus waarheen het verzonden wordt vol. Wanneer 
het besturingssysteem het bericht daadwerkelijk in de brievenbus kan depone- 
ren, wordt een bericht naar de verzender teruggestuurd; slechts één zo’n be- 
richt voor een volle brievenbus kan op elk moment voor een gegeven zendend 
proces hangende worden gehouden. 


De laatste mogelijkheid is bedoeld voor dienstverlenende processen, zoals het 
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stuurprogramma voor een regeldrukker. Na het voldoen aan een verzoek kan het 
nodig zijn dat deze processen een eenmalig antwoord naar het proces sturen dat 
om de verleende dienst had verzocht, maar ze moeten doorgaan met het voldoen 
aan andere verzoeken om dienstverlening, ook als de brievenbus voor een klant 
vol is. 

De ontvangbewerking moet aangeven uit welke brievenbus of brievenbus- 
sen een bericht ontvangen moet worden. Een proces kan alleen uit een brievenbus 
ontvangen als het voor die brievenbus ontvangsttoegang heeft. Bovendien kun- 
nen brievenbussen op slot zijn. Er kunnen geen berichten uit een brievenbus wor- 
den ontvangen die op slot zit. Een systeemaanroep Wachtende-Berichten retour- 
neert een lijst van de brievenbussen met wachtende berichten. De ontvangbewer- 
king probeert te ontvangen uit 1) een willekeurige niet op slot zittende brievenbus 
waartoe het proces ontvangsttoegang heeft, of 2) een specifieke (benoemde) brie- 
venbus. Als er geen bericht op ontvangst staat te wachten, kan het ontvangende 
proces wachten, hoogstens n milliseconden wachten, of niet wachten. 

Het Accent-systeem werd speciaal ontworpen voor gedistribueerde syste- 
men, die we bespreken in hoofdstuk 13, maar Accent is ook geschikt voor syste- 
men met één processor. Het belangrijkste probleem met berichtensystemen is 
in het algemeen het prestatievermogen geweest. Een speciaal probleem wordt 
veroorzaakt doordat eerst het bericht van de zender naar de brievenbus wordt 
gekopieerd en dan van de brievenbus naar de ontvanger. Het Accent- 
berichtensysteem tracht dubbele kopieerbewerkingen te vermijden door het ma- 
nipuleren van de paginatabel wanneer dat maar mogelijk is. Bijvoorbeeld, als een 
bericht van 512 bytes (één pagina) wordt verstuurd en ontvangen van en naar 
berichtenbuffers die beginnen bij een paginagrens, is het kopiëren van gegevens 
niet nodig; de ingang van de paginatabel voor het versturende proces wordt ge- 
woon in de paginatabel van het ontvangende proces gekopieerd. 


9.9 Samenvatting 


In dit hoofdstuk hebben we de algemene kwestie van parallellisme met betrek- 
king tot willekeurige algoritmen onderzocht. Binnen één enkel programma be- 
staan er voorrangsbeperkingen ten aanzien van de diverse opdrachten. Men kan 
gebruik maken van een voorrangsgraaf om deze beperkingen formeel uit te druk- 
ken. De condities van Bernstein kunnen worden gebruikt om te bepalen hoe een 
voorrangsgraaf voor een willekeurig programma kan worden geconstrueerd. 

Een programmeur kan de voorrangsrelaties tussen de diverse opdrachten 
in een programma opgeven, waarbij hij gebruik maakt van het begrip sequentieel 
proces. In het bijzonder zijn twee taalconstructies voor dit doel voorgesteld: de 
vertak/verbind-constructie en de parallel-opdracht (parbegin/parend). 

Het idee van parallelle uitvoering kan worden geformaliseerd door gebruik 
te maken van de begrippen: voorrangsgraaf en sequentieel proces. 

Bij een gegeven verzameling van met elkaar samenwerkende sequentiéle 
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processen die gebruik maken van een aantal gemeenschappelijke gegevens, moet 
gezorgd worden voor wederzijdse uitsluiting. Er bestaat een aantal verschillende 
algoritmen voor het oplossen van het kritieke-sectieprobleem, onder de aanname 
dat alleen impasses mogelijk zijn bij het verkrijgen van geheugenruimte. 

Het belangrijkste nadeel van deze oplossingen is dat deze alle uitgaan van 
de eis van wachten-in-een-lus. Semaforen hebben deze moeilijkheid niet. Van se- 
maforen kan gebruik worden gemaakt voor het oplossen van diverse synchronisa- 
tieproblemen en zij kunnen efficiënt worden geïmplementeerd. 

Een aantal verschillende synchronisatieproblemen (zoals het begrensde- 
bufferprobleem), het lezers/schrijversprobleem en het probleem van de tafelende 
filosofen) zijn belangrijk omdat zij voorbeelden zijn van een grote groep proble- 
men bij de besturing van parallellisme. Deze problemen worden gebruikt om 
bijna elke nieuw voorgestelde synchronisatiemethode te testen. 

Communicatie tussen processen kan het beste plaatsvinden door middel 
van een berichtensysteem. Berichtensystemen kunnen op tal van verschillende 
manieren worden gedefinieerd. 
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9.1 Zet de voorrangsgraaf van figuur 9.10 om in een programma, met ge- 
bruikmaking van: 
a. De parallel-opdracht. 
b. De constructie vertak/ verbind. 


9.2 Waarom is het nodig dat de verbind-instructie wordt uitgevoerd als een 
ondeelbare bewerking? 


9.3 Schrijf met behulp van de parbegin/parend-constructie een programma 
voor het implementeren van een methode met dubbele buffer waarbij 
geen gebruik wordt gemaakt van kopiëren. 


9.4 Het producent/consument-algoritme dat in paragraaf 9.5 werd bespro- 
ken staat toe dat slechts n—1 buffers op elk moment vol zijn. Wijzig het 
algoritme zo dat alle buffers volledig benut worden. Maak in uw oplos- 
sing geen gebruik van semaforen. 


9.5 Verklaar de noodzakelijkheid van wederzijdse uitsluiting. Wat is het mi- 
nimumniveau van wederzijdse uitsluiting dat noodzakelijk is voor de im- 
plementatie van bruikbare wederzijdse uitsluiting in besturingssys- 
temen? Welke andere vormen zijn nuttig? 


9.6 Beschouw de voorrangsgraaf van figuur 9.10. Stel dat we de pijl (02,04) 
aan de graaf toevoegen. 
a. Kan deze nieuwe voorrangsgraaf worden uitgedrukt met behulp van 
alleen de parallel-opdracht? Zo ja, laat zien hoe; indien niet, leg uit 
waarom niet. 
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ch 


Figuur 9.10 
Voorrangsgraaf 


9.7 


9.8 


9.9 


b. Hoe kan deze voorrangsgraaf worden uitgedrukt als ook semaforen 
kunnen worden gebruikt? 


Bewijs dat in het bakkersalgoritme de volgende eigenschap geldt: als P; 
zich binnen zijn kritieke sectie bevindt en Px (k # i) al zijn aantal[k] # 
0 heeft gekozen, dan is (aantallil,i) < aantal|k],k). 


Beschouw het voorbeeld van het oversteken van een rivier uit hoofdstuk 
8. Schrijf een algoritme voor het laten oversteken van een persoon vanaf 
oever A of oever B. Het algoritme moet de garantie geven dat verschillen- 
de personen vanaf dezelfde oever tegelijkertijd kunnen oversteken en dat 
daarbij geen impasses optreden. Laat zien hoe het algoritme kan worden 
uitgebreid zodat ook verhongering vermeden wordt. 


Het volgende algoritme, te danken aan Dekker, is de eerst bekende cor- 
recte programmatuur-oplossing voor het kritieke-sectieprobleem voor 
twee processen. De twee processen, Po en Pi, hebben de volgende varia- 
belen gemeen: 


var vlag: array[0..1] of boolean; (* beginwaarde: false *) 
beurt: 0..1; 
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Het onderstaande programma geldt voor proces P; (i = 0 of 1), waarbij 
proces P; (j = 1 of 0) het andere proces is. 


repeat 
viagli] : = true; 
while viag{j] 
do if beurt = j 
then begin 
vlagli) := false; 
while beurt = j do skip; 
vlagļ[i] : = true; 
end; 
kritieke sectie 
beurt := j; 


vlagļi] := false; 


rest-sectie 
until false; 


Bewijs dat het algoritme voldoet aan alle drie de vereisten voor het kri- 
tieke-sectieprobleem. 


9.10 Toon aan dat als de P- en V-bewerkingen niet atomisch worden uitge- 
voerd, aan de voorwaarde van wederzijdse uitsluiting wellicht niet vol- 
daan is. 


9.11 Een binaire semafoor is een semafoor die alleen de gehele waarde 0 of 1 
kan hebben. Laat zien hoe een algemene semafoor kan worden geïmple- 
menteerd door binaire semaforen te gebruiken. 


9.12 Wachtlijsten voor semaforen worden vaak geïmplementeerd als wacht- 
rijen die FIFO worden afgewerkt. Zouden ze als stapels kunnen worden 
geïmplementeerd? Welke problemen zouden hierdoor kunnen ontstaan? 


9.13 Beschouw een verzameling sequentiële processen die geen variabelen ge- 
meen kunnen hebben behalve semaforen. Kunnen deze processen met 
elkaar communiceren? (Aanwijzing: het is voldoende de transmissie van 
één enkele bit te beschouwen.) 


9.14 Twee synchronisatiefuncties, INRIJ en UITRIJ, zijn als volgt gedefi- 
nieerd: s is een systeemelement, p is een proces, wachtrij(s) is een FIFO- 
wachtrij van processen die staan te wachten op het verkrijgen van sys- 
teem-element s, en ingebruik(s) is een booleaanse variabele. . 


9.15 


9.16 


9.17 


9.18 
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INRIJ(s): if ingebruik(s) 
then begin 
plaats p in wachtrij(s); 
blokkeer p; 
end 
else ingebruik(s) := true; 
UITRIJ(s): p := top-element in wachtrij(s); 
if p # nil 
then activeer p; 
else ingebruik(s) := false; 


Maak een implementatie van INRIJ/UITRIJ met gebruikmaking van 
semaforen. Zorg dat u er zeker van bent dat de volgordebepaling die in 
het reactiveren van het proces ligt besloten correct geimplementeerd is. 
Gebruik extra gegevensstructuren en variabelen als u die nodig heeft. 


Wat is de betekenis van de term wachten-in-een-lus? Welke andere soor- 
ten wachten zijn er? Kan wachten-in-een-lus geheel worden vermeden? 


Schrijf een algoritme voor het implementeren van semaforen door ge- 
bruik te maken van: 

a. De Wissel-instructie. 

b. De Test-en-Zet-instructie. 


Een meervoudige semafoor maakt het mogelijk dat de functies P en V 
op meerdere semaforen tegelijk werken. Dit is nuttig voor het verkrijgen 
en vrijgeven van verschillende systeemelementen in één atomische be- 
werking. Zo kan de P-functie (voor twee semaforen) als volgt worden 
gedefinieerd: 


P(S,R): while (S < Oor R < 0) do skip; 
S:= S- l; 
R:=R-1; 


Laat zien hoe een meervoudige semafoor kan worden geimplementeerd 
door gebruik te maken van gewone semaforen. 


De volgende ’oplossing’ voor het kritieke-sectieprobleem werd gegeven 
door Hyman [1966]. Bepaal of deze correct is. Als hij incorrect is, geef 
dan een voorbeeld dat in strijd is met één van de drie vereisten voor het 
kritieke-sectieprobleem. 

De twee processen Po en Pi hebben de volgende variabelen ge- 
meen: 


var vlag: array[0..1] of boolean; (* beginwaarde: false *) 
beurt: 0..1; 
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Het onderstaande programma geldt voor proces P; (i = 0 of 1), waarbij 
proces P; (j = 1 of 0) het andere proces is. 


repeat 
vlagļi] := true; 
while beurt # i 
do begin 
while vlag{y] do skip; 
beurt := i; 
end 


kritieke sectie 


vlagli] : = false; 
rest-sectie 
until false; 
9.19 Is wachten-in-een-lus een eigenschap van de P/ V-oplossing voor proces- 
= synchronisatie en wederzijdse uitsluiting? 


9.20 Beschouw een systeem dat een manier van communicatie tussen proces- 
sen ondersteunt maar geen semaforen kent. Geef aan welke declaraties 
en code nodig zouden zijn om een wisselwerking te programmeren die 
gebruik wil maken van P- en V-bewerkingen op semaforen, in plaats 
van zend/ontvang. U moet laten zien hoe de P- en V-bewerkingen en 
semaforen moeten worden voorgesteld door gebruik te maken van de 
zend/ontvang-bewerkingen en berichten. 


9.21 [Dijkstra 1965a] Het Probleem van de Slapende Kapper. Een kapperszaak 
bestaat uit een wachtkamer met n stoelen en de kapperssalon met de 
kappersstoel. Als er geen klanten zijn om geholpen te worden valt de 
kapper in slaap. Als een klant de kapperszaak binnenkomt en alle stoelen 
bezet zijn, verlaat de klant de zaak. Als de kapper bezig is, gaat de klant 
op één van de onbezette stoelen zitten. Als de kapper slaapt, maakt de 
klant de kapper wakker. Schrijf een programma om de kapper en de 
klanten te coördineren. 


9.22 [Patil 1971] Het Probleem van de Sigarettenrokers. Beschouw een systeem 
met drie roker-processen en één tussenpersoon-proces. Iedere roker rolt 
voortdurend een sigaret en rookt deze op. Maar voor het draaien en 
oproken van een sigaret zijn drie ingrediënten nodig: shag, vloeitjes en 
lucifers. Een van de processen heeft vloeitjes, een ander heeft shag en 
het derde heeft lucifers. De tussenpersoon heeft een oneindig grote voor- 
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raad van alle drie. De tussenpersoon plaatst twee van de ingrediënten 
op de tafel. De roker die het overblijvende ingrediënt heeft kan dan een 
sigaret draaien en oproken, waarna hij, als hij klaar is, de tussenpersoon 
een seintje geeft. De tussenpersoon plaatst dan weer twee van de in- 
grediënten op de tafel en de cyclus herhaalt zich. Schrijf een programma 
om de tussenpersoon en de rokers te synchroniseren. 


9.23 Beschouw een systeem van processen die alleen via pijpen communi- 
ceren. Pijpen zijn wachtrijen voor berichten met éénrichtingsverkeer, 
waarbij gebruik gemaakt wordt van een gemeenschappelijke systeem- 
bufferpot. Elke pijp heeft precies één producent- en één consument-pro- 
ces. 

a. Onder welke omstandigheden zal een proces worden gedwongen te 
wachten in dit systeem? 

b. Geef voor dit systeem een geschikt mechanisme aan voor het opspo- 
ren van impasses. 

c. Als u een impasse ontdekt heeft en een ’slachtoffer’proces heeft geko- 
zen dat moet worden beëindigd, wat moet u dan doen met de bericht- 
en-wachtrijen? 

d. Stel een regel op voor het uitkiezen van het slachtoffer, en leg uit 
waarom deze regel goed is. 


9.24 Beschouw het systeem voor communicatie tussen processen dat gebruik 
maakt van brievenbussen. 

a. Stel dat een proces P wil wachten op een bericht uit brievenbus A en 
uit brievenbus B (uit elk één). Welke serie zend- en ontvang-opdrach- 
ten moet het uitvoeren? | 

b. Welke serie zend- en ontvang-bewerkingen moet er plaatsvinden als 
P wil wachten op een bericht van óf brievenbus A óf brievenbus B 
(of beide)? 

c. Een ontvang-bewerking laat een proces wachten tot de brievenbus 
niet-leeg is. Kunt u een schema bedenken waarbij we een proces laten 
wachten tot een brievenbus leeg is? 


9.25 Geef een impassevrije oplossing voor het probleem van de tafelende 
filosofen. Garandeert uw oplossing dat er geen verhongering optreedt? 
Zo ja, leg uit waarom; indien niet, wijzig dan uw algoritme zodat het een 
oplossing geeft die niet tot verhongering kan leiden. 


Bibliografische verwijzingen 
De begrippen parallel-opdrachten, kritieke secties en semaforen werden alle geïn- 


troduceerd in het klassieke artikel van Dijkstra [1965a]. Dit artikel gaf ook de 
algoritmen 1 tot en met 4 voor de wederzijdse uitsluiting van twee processen 
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en besloot met het algoritme van Dekker (zie Opgave 9.9), de eerste correcte 
programmatuuroplossing voor het probleem van de wederzijdse uitsluiting van 
twee processen. Het is te danken aan de Nederlandse wiskundige T. Dekker. 
Eenvoudiger oplossingen voor het probleem van de wederzijdse uitsluiting van 
twee processen zijn sindsdien gegeven door Doran en Thomas [1980] en Peterson 
[1981]. 

De eerste oplossing voor het probleem van de wederzijdse uitsluiting voor 
n processen werd gegeven door Dijkstra [1965b]. Een eenvoudiger oplossing is 
gegeven door Peterson [1981]. Geen van deze oplossingen heeft echter een boven- 
grens voor de hoeveelheid tijd die een proces moet wachten voordat het de kritie- 
ke sectie mag binnengaan. Knuth [1966] gaf het eerste algoritme met een grens. 
Zijn grens was 2" beurten. Een verfijning van Knuth’s algoritme door DeBruijn 
[1967] bracht de wachttijd terug tot n? beurten, terwijl Eisenberg en McGuire 
[1972] erin slaagden de tijd terug te brengen tot de ondergrens van n—1 beurten. 
Het bakkersalgoritme van Lamport [1974] vereist ook n—1 beurten, maar het is 
gemakkelijker te programmeren en te begrijpen. 

Complexiteit ontstaat als gevolg van het aantal gemeenschappelijke varia- 
belen dat nodig is voor het implementeren van de diverse algoritmen voor weder- 
zijdse uitsluiting bij n processen die gegeven zijn door Burns [1978], Burns en 
Lynch [1980] en Burns et al. [1982]. 

Besprekingen van de diverse aspecten van semaforen worden gegeven door 
Dijkstra [1965a, 1968b, 1971] en Habermann [1972]. De namen van de P- en 
V-bewerkingen zijn afkomstig van de Nederlandse termen proberen en verhogen 
(ophogen van een variabele). Vele auteurs (zoals Brinch Hansen [1973a]) geven 
de voorkeur aan wait (wacht, in plaats van P) en signal (sein, in plaats van V). 

Patil [1971] onderzocht de vraag of semaforen alle mogelijke synchronisa- 
tieproblemen kunnen oplossen. Parnas [1975a] besprak enkele onjuistheden in 
Patil's argumenten. Kosaraju [1973] en Agerwala en Flynn [1973] leverden een 
vervolg op Patil’s werk door een probleem aan te geven dat niet met behulp van 
P- en V-bewerkingen kan worden opgelost. Soortgelijke ontdekkingen deed Kel- 
ler [1972]. Lipton [1974] heeft de beperking van diverse synchronisatiefuncties 
besproken, zoals het PV-veelvoud [Patil 1971], PV algemeen [Cerf 1972] en PV- 
brok (Engels: ’PV chunk’) [Vantilborgh en Van Lamsweerde 1972]. Nog andere 
resultaten betreffende deze kwesties worden beschreven door Henderson en Zalc- 
stein [1980]. 

De klassieke problemen van procescoördinatie die we hebben beschreven 
staan model voor een grote groep problemen bij de besturing van parallellisme. 
Het begrensde-bufferprobleem en het probleem van de tafelende filosofen wer- 
den te berde gebracht door Dijkstra [1965a, 1971]. De lezers/ schrijversproblemen 
werden geintroduceerd door Courtois et al. [1971]. 

Besprekingen betreffende het begrip ’proces’ en zijn implementatie worden 
gegeven door Horning en Randell [1973], Brinch Hansen [1970] (het RC 4000 
systeem), Dijkstra [1968b] (het THE-systeem) en Liskov [1972a] (het Venus-sys- 
teem). 
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Het onderwerp communicatie tussen processen wordt besproken door Mo- 
renoff en McLean [1967], Brinch Hansen [1970] (het RC 4000 systeem) en Cheri- 
ton et al. [1979] (het Thoth onvertraagde-besturingssysteem). Brinch Hansen 
[1970] was de eerste die het gebruik van berichten voor synchronisatie voorstelde. 

Artikelen die een inleiding en een overzicht bieden zijn onder meer die 
van Presser [1975] en Atwood [1976]. Besprekingen die gedegen leerstof vormen 
worden gegeven door Brinch Hansen [1973a, hoofdstuk 3], Shaw [1974, hoofd- 
stuk 3], Tsichritzis en Bernstein [1974, hoofdstuk 2] en Habermann [1976, hoofd- 
stukken 3 en 4]. 


10 


PARALLEL-PROGRAMMERING 


Besturingssystemen worden tegenwoordig bijna altijd in een syteemimplemen- 
tatietaal of in een hogere programmeertaal geschreven. Deze voorziening be- 
tekent een verbetering voor de implementatie, het onderhoud en de overdraag- 
baarheid (Engels: portability). In dit hoofdstuk gaan we de ontwikkeling van 
hogere-programmeertaalconstructies voor parallel-programmering na. 


10.1 Beweegredenen 


Een besturingssysteem bestaat uit een groot aantal programma’s die asynchroon 
werken en die met elkaar samenwerken om de taak van het besturingssysteem 
uit te voeren. Voorheen werden deze programma’s in assembleertaal geschreven 
en wel om drie redenen: 


@ Hogere programmeertalen hadden geen voorzieningen voor het schrijven van 
machine-onafhankelijke code (zoals de stuurprogramma’s voor randappara- 
tuur). 

@ Hogere programmeertalen bevatten niet de juiste hulpmiddelen voor het 
schrijven van parallele (concurrent) programma’s. 

@ Hogere programmeertalen waren voor parallelle programma’s niet efficiënt. 


De laatste tijd echter hebben we nieuwe talen geformuleerd zien worden die pa- 
rallellisme ondersteunen en betrekkelijk efficiënt zijn. Bovendien waren vele van 
de argumenten tegen het gebruik van hogere programmeertalen gebaseerd op de 
veronderstelling dat de taal in kwestie gebruikt moet worden om de centrale 
functies van een besturingssysteem te programmeren: bijvoorbeeld het fysieke 
geheugenbeheer, het procesbeheer en de beveiligingskern. Het merendeel van de 
code van een besturingssysteem heeft echter niets van doen met het leveren van 
besturingssysteemfuncties op dit niveau. Daarom hoeft deze code, als men over 
de juiste hogere programmeertaal beschikt, niet in assembleertaal geschreven te 
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worden. 


Er zitten voordelen aan het gebruik van een hogere programmeertaal in 
plaats van assembleertaal. Programma's in een hogere programmeertaal zijn een- 
voudiger en gemakkelijker te testen en te verifiëren, te wijzigen en van de ene 
naar de andere machine over te brengen. Het gevolg is dat de programmeur min- 
der tijd kwijt is met het ontwikkelen en testen van programma’s. 

Het belangrijkste nadeel van een hogere programmeertaal is het probleem 
dat er inefficiënte code wordt gegenereerd. Dit probleem kan worden opgelost 
door verschillende technieken ter optimalisering van het compileerprogramma te 
gebruiken. We hebben nu optimaliserende compileerprogramma’s die code ge- 
nereren die minstens zo goed is als die van met de hand geschreven programma’s 
in assembleertaal. De mate van optimalisering die door een compileerprogramma 
kan worden bereikt hangt uiteraard sterk af van de hogere programmeertaal. Het 
is de verantwoordelijkheid van de ontwerper van de taal om te garanderen dat 
de voorgestelde taalconstructies efficiënt geïmplementeerd kunnen worden. 

In dit hoofdstuk hebben we hoofdzakelijk te maken met hogere program- 
meertalen die gebruikt moeten worden voor het schrijven van parallelle program- 
ma’s. Zulke talen moeten voorzieningen bieden voor modulaire opbouw en 
synchronisatie. 


10.2 Modulaire opbouw 


Modulaire opbouw is de term die gebruikt wordt om aan te geven dat we één 
groot programma splitsen in een groep kleinere modulen. In deze paragraaf zul- 
len we een overzicht geven van de soorten modulen die we verwachten aan te 
treffen in een besturingssysteem dat in een of andere hogere programmeertaal 
geschreven is. 


10.2.1 Processen 


Zoals we in de hoofdstukken 4 en 9 zagen, is een proces een fundamenteel begrip 
in het ontwerp van een besturingssysteem. Een besturingssysteem is opgebouwd 
uit een aantal asynchrone processen die moeten communiceren en die hun acties 
moeten synchroniseren. 

In het minst strikte geval kunnen processen al hun variabelen gemeenschap- 
pelijk gebruiken. In dit geval moeten programmeurs, om te waken voor tijdafhan- 
kelijke fouten, hun eigen synchronisatiemethoden ontwikkelen. Het compileer- 
programma kan de programmeur hierbij niet helpen. In het geval met de meeste 
beperking hebben processen totaal geen gemeenschappelijke variabelen. Commu- 
nicatie en synchronisatie kunen alleen plaatsvinden met behulp van een voorzie- 
ning voor het uitwisselen van berichten, die we in hoofdstuk 9 hebben besproken, 
of doordat afzonderlijke procedures elkaar parameters doorgeven, wat we in dit 


10.2 Modulaire opbouw 377 


hoofdstuk zullen bespreken. Het compileerprogramma kan tijdens het vertalen 
de zekerheid geven dat er geen gebruik wordt gemaakt van gemeenschappelijke 
variabelen, zodat er geen tijdafhankelijke fouten zullen optreden als gevolg van 
gemeenschappelijk gebruikte variabelen. 

Op deze manier bestaat een proces uit een aantal lokale gegevens en een 
sequentieel programma dat met deze gegevens kan werken (zie figuur 10.1). Tot 
de lokale gegevens heeft alleen het programma toegang dat binnen dat zelfde 
proces besloten ligt. Dat wil zeggen, het ene proces heeft niet rechtstreeks toegang 
tot de gegevens van een ander proces. Als processen gemeenschappelijk gebruik 
kunnen maken van globale gegevens moeten deze gegevens óf in een gemeen- 
schappelijk gebied zijn gedefinieerd, óf besloten zijn in een procedure of een 
abstract gegevenstype zoals dat in de volgende paragraaf wordt beschreven. 


10.2.2 Procedures 


Een ander soort module is de procedure (subroutine) of functie die we in elke 
hogere programmeertaal verwachten aan te treffen. Als een procedure zijn eigen 
persistente variabelen (dat zijn variabelen die niet tussen twee opeenvolgende 
aanroepen van de procedure verloren gaan) kan omsluiten, dan kunnen er be- 
paalde globale gegevens binnen een procedure ingekapseld worden. Op deze wij- 
ze kan een proces niet rechtstreeks bij deze gegevens komen; het moet voor dat 
doel de procedure aanroepen. 

Deze inkapseling schermt de details van de implementatie af van de gebrui- 


reeks 
opdrachten 


Figuur 10.1 
Schematisch overzicht van een proces 
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kers van de procedure, zodat zij zich kunnen concentreren op het gebruik maken 
van de procedure, in plaats van op de manier waarop de procedure in feite geim- 
plementeerd is. 


10.2.3 Abstracte gegevenstypen 


Een procedure biedt ons een beperkt mechanisme voor het afschermen van infor- 
matie. Om de manier waarop de gegevens gedefinieerd zijn volledig te verbergen 
moeten we onze toevlucht nemen tot een gecompliceerder stel mechanismen. We 
hebben een voorziening nodig die een programmeur toestaat een groep van ab- 
stracte objecten te creëren die niet expliciet voorzien waren in het ontwerp van de 
programmeertaal. Dit soort mechanisme wordt in een aantal programmeertalen 
beschikbaar gesteld. Gewoonlijk wordt het aangeduid met de term abstract ge- 
gevenstype. Een abstract gegevenstype wordt gekenmerkt door een groep opera- 
toren die door de programmeur gedefinieerd zijn. De weergave van een abstract 
gegevenstype bestaat uit declaraties van variabelen waarvan de waarden zowel 
de toestand van een exemplaar van het type bepalen als de rompcode van de 
procedures of functies die bewerkingen op het type implementeren (zie figuur 
10.2). 

Het klassieke voorbeeld van een abstract gegevenstype is een stapel (En- 
gels: stack). De meeste programmeertalen voorzien niet op dezelfde manier in 
stapels als ingebouwde gegevenstypen als waarop ze voorzien in gehele getallen 


Bewerkingen 


Initialiserings- 
code 


Figuur 10.2 
Schematisch overzicht van een abstract gegevenstype 
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(integers), reeksen (arrays) en andere basistypen. Daarom is een stapel een ge- 
gevenstype dat door de programmeur gedefinieerd is, niet door de taal. Een stapel 
heeft een groepje welomschreven bewerkingen (erop zetten, eraf halen, leeg ma- 
ken, bovenaan zetten, enzovoort). Een stapel moet alleen maar benaderd worden 
via deze bewerkingen; elementen van de stapel mogen nooit rechtstreeks geadres- 
seerd worden. 

We noemen een programmamodule die de weergave van een abstract ge- 
gevenstype voorstelt een klasse (Engels: class). Deze term werd geïntroduceerd 
in Simula 67 [Dahl et al. 1968] en wordt gebruikt in de taal Concurrent Pascal 
[Brinch Hansen 1975]. De syntaxis van een klasse is: 


type klassenaam = class 
declaraties van variabelen 


procedure P1 ( ... ); 
begin ... end; 


procedure P2 ( ... ); 
begin ... end; 


procedure Pn (... ); 
begin ... end; 


begin 
initialiseringscode 
end. 


Het is zonder meer duidelijk dat de representatie van een abstract gegevens- 
type niet rechtstreeks door andere componenten van het programma dan door 
de desbetreffende bewerkingen moet worden gebruikt; anders zou de abstractie 
gevaar lopen niet consistent te zijn. Deze beperking is de fundamentele eis die is 
opgelegd aan een taal die abstracties ondersteunt die door de programmeur zijn 
gedefinieerd. Op deze wijze kan een procedure die binnen een klasse gedefinieerd 
is alleen de variabelen die lokaal binnen de klasse gedeclareerd zijn en de formele 
parameters benaderen. Evenzo kunnen de lokale variabelen van een klasse alleen 
door de lokale procedures benaderd worden. 

Het mechanisme waarmee de implementatie van een taal statische hand- 
having van de bescherming geeft voor de typen die door modulen gedefinieerd 
zijn berust op een herformulering van de traditionele geldigheidsgebied-regels 
van talen die werken met blokstructuren. Een module exporteert de namen (en 
typen) van zijn bewerkingen, maar niet de representatie van het type dat hij de- 
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finieert. Een gebruiker van een abstract gegevenstype kan alleen de bewerkingen 
aanroepen die geëxporteerd worden. Als een nieuw type niet wordt geëxporteerd, 
kunnen gebruikers exemplaren van dat type definiëren. De gebruikers kunnen 
echter niet rechtstreeks op de elementen bewerkingen uitvoeren. Rechtstreekse 
toegang tot de representatie van het type kan alleen plaatsvinden binnen de klas- 
se waarin het nieuwe type is gedefinieerd. 

Een klasse hoeft niet al zijn procedures te exporteren. Om onderscheid te 
maken tussen de procedures die wel worden geëxporteerd en die niet, gebruiken 
we de notatie: 


procedure entry P ( ... ); 


Alleen entry-procedures (ingang-procedures) kunnen van buiten de klasse wor- 
den aangeroepen. | 

Laten we deze begrippen illustreren aan de hand van een eenvoudig, maar 
sprekend, voorbeeld. Stel dat we een klasse willen definiëren voor het distribue- 
ren van geheugen van een vaste omvang (zoals pagina’s in het interne geheugen 
of blokken op een schijf). De informatie aangaande het vrije geheugen wordt 
bijgehouden in een bitvector (zie paragraaf 3.4), die ingekapseld is binnen de 
klasse kaders die hierna beschreven wordt. 


type kaders = class 
var vrij: array[1..n] of boolean; 


procedure entry verkrijg (var index: integer); 
begin 
for index := | ton 
do if vrijlindex] 
then begin 
vrijlindex] := false; 
exit; 
end; 
index := -1; 
end 


procedure entry geefvrij (index: integer); 


vrijlindex] := true; 
end; 
begin 
for index := 1 ton 


do vrijlindex] := true; 
end. 
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Een exemplaar van de klasse kaders (bijvoorbeeld voor geheugenbeheer) 
kan worden verkregen door te declareren: 


var geheugen: kaders; 
Een proces dat een vrije pagina nodig heeft zal uitvoeren: 
geheugen.verkrijg (in); 


Als er geen vrije pagina beschikbaar is, zal de variabele in op — 1 gezet worden. 
Op dit punt aangekomen moet het proces óf wachten óf om programmaverwis- 
seling verzoeken. Het proces kan de toegewezen pagina teruggeven door de uit- 
voering van: 


geheugen geefvrij (in); 


Nadat deze procedure is uitgevoerd kan de teruggegeven pagina weer aan een 
ander proces worden toegewezen. 

Het voordeel van het als een klasse definiëren van kaders is dat we de imple- 
mentatie van kaders gemakkelijk kunnen wijzigen zonder het gebruik ervan te 
wijzigen. Het zou bijvoorbeeld gemakkelijk zijn om de implementatie met een 
bitvector te wijzigen in een implementatie die een aaneengeschakelde lijst ge- 
bruikt. Alleen de klassedeclaratie dient dan veranderd te worden. 
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In het voorbeeld van de kaders kunnen verschillende processen de procedures 
verkrijg en geefvrij tegelijkertijd aanroepen. Deze situatie kan inconsistente gege- 
vens tot gevolg hebben (twee processen kunnen bijvoorbeeld hetzelfde vrije kader 
vinden). Om tegen deze mogelijkheid bescherming te bieden moet de taal ook 
geschikte instrumenten voor synchronisatie leveren. 

Een taal moet de middelen voor bescherming tegen tijdafhankelijke fouten 
bieden. Zulke fouten kunnen optreden indien verschillende parallelle processen 
met elkaar communiceren met behulp van gemeenschappelijke variabelen of 
expliciete berichten. We zouden uiteraard dit type communicatie volledig kunnen 
verbieden, waardoor tijdafhankelijke fouten uit de wereld geholpen zouden zijn. 
Deze beperking zou evenwel de mate van parallellisme die in een besturingssys- 
teem is toegestaan drastich verminderen. Het is duidelijk dat deze oplossing niet 
levensvatbaar is. Daarom zullen we naar een compromis moeten zoeken. In 
plaats van ons volledig van tijdafhankelijke fouten te ontdoen zullen we taalcon- 
structies moeten leveren die hun aantal aanzienlijk terugbrengen. 
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10.3.1 Kritieke regio’s 


Semaforen kunnen doeltreffend worden gebruikt voor het oplossen van het kri- 
tieke-sectieprobleem, maar ook voor willekeurige synchronisatiemethoden. Laten 
we nog eens kijken naar het kritieke-sectieprobleem. Alle processen maken ge- 
meenschappelijk gebruik van een variabele weduit, die de beginwaarde 1 krijgt. 
Elk proces moet P(weduit) uitvoeren alvorens de kritieke sectie binnen te gaan 
en V(weduit) na het verlaten daarvan. Als men zich niet aan deze volgorde houdt 
kunnen twee processen tegelijk in hun kritieke secties zijn, met tijdafhankelijke 
fouten als resultaat. 

Laten we de verschillende moeilijkheden die hiervan het gevolg kunnen zijn 
onderzoeken. Merk op dat deze moeilijkheden zullen optreden zelfs als één enkel 
proces zich niet behoorlijk gedraagt. Deze situatie kan optreden als gevolg van 
een eerlijke programmeerfout of een programmeur die niet goed meewerkt. 


@ Stel dat een proces de bewerkingen op de semafoor weduit verwisselt. Dat wil 
zeggen, het voert uit: 


V(weduit); 
kritieke sectie 
P(weduit); 


In deze situatie kunnen diverse processen tegelijk in hun kritieke sectie aan de 
uitvoering bezig zijn, waardoor de eis van wederzijdse uitsluiting geweld wordt 
aangedaan. Deze tijdafhankelijke fout kan alleen ontdekt worden als verschil- 
lende processen tegelijk in hun kritieke secties actief zijn. Let erop dat deze 
situatie niet altijd reproduceerbaar hoeft te zijn. 

@ Stel dat een proces V(weduit) verwisselt met P(weduit). Dat wil zeggen, het 
voert uit: 


P(weduit); 
kritièke sectie 
P(weduit); 
In deze situatie zal een impasse optreden. 
@ Stel dat een proces de P(weduit) of de V(weduit), of beide, weglaat. In dit geval 


wordt óf de wederzijdse uitsluiting geschonden óf zal er een impasse optreden. 


Het bovenstaande voorbeeld laat zien dat tijdafhankelijke fouten gemakke- 
lijk kunnen ontstaan bij gebruik van semaforen om het kritieke-sectieprobleem 
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op te lossen. Om dit gebrek te ondervangen voerden Brinch Hansen [1972b] en 
Hoare [1972b] een nieuwe taalconstructie in: de kritieke regio. We kunnen een 
variabele v van het type T declareren, die door vele processen gemeenschappelijk 
gebruikt (Engels: shared) moet worden: 


var v: shared 7; 


De variabele v kan alleen worden benaderd binnen een regio-opdracht (Engels: 
region) van de volgende vorm: 


region v do O; 


Deze constructie betekent dat, terwijl opdracht O wordt uitgevoerd, geen ander 
proces de variabele v kan benaderen. Dus als de twee opdrachten 


region v do O1; 
region v do O2; 


parallel worden uitgevoerd door afzonderlijke sequentiële processen, zal het re- 
sultaat gelijkwaardig zijn aan de sequentiële uitvoering ’O1 gevolgd door O2’, of 
’O2 gevolgd door OP. 

We lichten dit denkbeeld toe aan de hand van de klasse kaders die gedefi- 
nieerd werd in paragraaf 10.2.3. Daar voor het benaderen van de reeks vrij weder- 
zijdse uitsluiting is vereist, moeten we deze declareren als een gemeenschappelijk | 
gebruikte reeks (Engels: shared array): 


var vrij: shared array[1..n] of boolean; 
De verkrijg-procedure moet als volgt worden herschreven: 
procedure entry verkrijg (var index: integer); 

begin 


region vrij 
do for index := 1 ton 


do if vrij[index] 
then begin 
vrijlindex] := false; 
exit; 
end; 
index := —1; 


end; 


Het blijkt dat de geefvrij-procedure en het initialiseringsgedeelte van de klasse 
kaders niet herschreven hoeven te worden. We laten het bewijs van deze bewering 
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over aan de lezer. 


De kritieke-regioconstructie biedt bescherming tegen enkele eenvoudige 
fouten die met de semafooroplossing van het kritieke-sectieprobleem samenhan- 
gen en die door een programmeur gemaakt kunnen zijn. Let erop dat dit tijdaf- 
hankelijke fouten niet noodzakelijk elimineert, maar in plaats daarvan hun aantal 
terugbrengt. Als er fouten in de logica van het programma voorkomen, kan het 
reproduceren van een speciale volgorde van gebeurtenissen wel eens niet zo’n 
simpele zaak zijn. 

We laten nu zien hoe een compileerprogramma de constructie van de kritie- 
ke regio zou kunnen implementeren. Voor elke declaratie 


var v: shared 7; 


genereert het compileerprogramma een semafoor v-weduit die de beginwaarde 1 
krijgt. Voor elke opdracht 


region v do O; 
genereert het compileerprogramma de volgende code: 


P(v-weduit); 
O; 
V(v-weduit); 


Het is duidelijk dat wederzijdse uitsluiting in acht wordt genomen zoals dit wordt 
vereist door de betekenis van de kritieke-regio-opdracht. 

Kritieke regio’s kunnen ook genest zijn. In dat geval kunnen echter impas- 
ses optreden. Het volgende programma laat deze situatie zien: 


var x,y: shared T; 
parbegin 
Q: region x do region y do OJ; 
R: region y do region x do O2; 
parend; 


Als P en Q ongeveer gelijktijdig respectievelijk de regio’s x en y binnengaan, zal 
er een impasse optreden. Bekijk de volgende uitvoeringsvolgorde, waarbij van 
semaforen gebruik wordt gemaakt om de constructie van de kritieke regio te 
implementeren. 


To: Q voert uit P(x-weduit). 
Tı: R voert uit P(y-weduit). 
Tz: R voert uit P(x-weduit), R wacht omdat x-weduit 
T3: Q voert uit P(y-weduit), Q wacht omdat y-weduit 


| 
= > 
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We hebben nu een impassesituatie waarbij Q en R betrokken zijn. De im- 
passe treedt op omdat regio x genest is in regio y en omgekeerd. Om zo’n situatie 
te voorkomen kan een ordening van systeemelementen worden opgelegd (zie pa- 
ragraaf 8.3.4). Als zo’n ordening niet kan worden opgezet kunnen er impasses 
optreden. Het compileerpogramma kan de mogelijkheid van zulke impasses ont- 
dekken en foutmeldingen geven om de programmeur van de situatie op de hoogte 
te stellen. Het compileerprogramma zou het feit dat twee regio’s genest zijn ge- 
bruiken om als volgt een binaire relatie te definiëren. Als we twee regio’s x en y 
hebben zodanig dat regio y genest is in regio x, dan stellen we per definitie y < x. 
Als deze binaire relatie een gedeeltelijke ordening voorstelt kan er geen impasse 
optreden. | 


10.3.2 Voorwaardelijke kritieke regio’s 


De constructie van de kritieke regio kan doeltreffend worden gebruikt om het 
kritieke-sectieprobleem op te lossen. Het kan echter niet gebruikt worden om een 
aantal algemene synchronisatieproblemen op te lossen. Om deze reden werd de 
voorwaardelijke kritieke regio geïntroduceerd door Hoare [1972b]. Het belangrijk- 
ste verschil tussen de constructies van de kritieke regio en de voorwaardelijke 
kritieke regio zit in de regio-opdracht, die nu de vorm heeft: 


region v when B do O; 


waarin B een booleaanse uitdrukking is. Evenals eerder sluiten regio’s die naar 
dezelfde gemeenschappelijke variabele verwijzen elkaar in de tijd uit. Nu wordt 
evenwel, wanneer een proces de kritieke sectie binnenkomt, de waarde van de 
booleaanse uitdrukking B bepaald. Als de uitdrukking waar is wordt de opdracht 
O uitgevoerd. Is hij niet-waar, dan geeft het proces de wederzijdse uitsluiting op 
en moet het wachten tot B waar wordt en er zich geen ander proces bevindt in 
de regio die met v verbonden is. 

Laten we deze begrippen toelichten aan de hand van het begrensde-buffer- 
probleem dat we nu zullen coderen. De bufferruimte en Zijn wijzers zijn ingekap- 
seld in: 


var buffer: shared record 
pot: array [0..n—1] of artikel; 
aantal, in, uit: integer; 
end; 


Het producent-proces voegt een nieuw artikel volgendep aan de buffer toe door 
de uitvoering van: 
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region buffer when aantal < n 
do begin 
pot{in] := volgendep; 
in := in+ 1 mod n; 
aantal := aantal + 1; 
end; 


Het consument-proces verwijdert een artikel uit de gemeenschappelijk gebruikte 
buffer en plaatst dit in volgendec door de uitvoering van: 


region buffer when aantal > 0 
do begin 
volgendec := pot{uit}; 
uit := uit+ 1 mod n; 
aantal := aantal — 1; 
end; 


Laten we eens zien hoe de voorwaardelijke kritieke regio door een com- 
pileerprogramma geïmplementeerd zou kunnen worden. Met iedere gemeen- 
schappelijk gebruikte variabele x worden de volgende variabelen verbonden: 


var x-weduit, x-wacht: semafoor; 
x-aantal, x-hulp: integer; 


Toegang tot de kritieke sectie met wederzijdse uitsluiting wordt gegeven door 
x-weduit. Als een proces de kritieke sectie niet kan binnenkomen omdat de 
booleaanse voorwaarde niet-waar (false) is, wacht het op de semafoor x-wacht. 
We houden het aantal van de processen die wachten op x-wacht bij door middel 
van x-aantal. Wanneer een proces de kritieke sectie verlaat kan het de waarde 
hebben gewijzigd van een booleaanse voorwaarde B die een ander proces verhin- 
derde de kritieke sectie binnen te komen. Daarom moeten we de wachtrij van de 
processen die wachten op x-wacht langs gaan om ieder proces de gelegenheid te 
geven zijn booleaanse voorwaarde te testen. We gebruiken x-hulp om te bepalen 
wanneer we elk proces de gelegenheid hebben gegeven zijn conditie te testen. In 
overeenstemming daarmee wordt x-weduit in het begin op | gezet, terwijl x-wacht, 
x-aantal en x-hulp de beginwaarde 0 krijgen. Een opdracht 


region x when B do O; 


kan als volgt worden geïmplementeerd: 
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P(x-weduit) 
if not B 
then begin 
x-aantal := x-aantal + 1; 
V(x-weduit); 
P(x-wacht); 
while not B 
do begin 
x-hulp := x-hulp + 1; 
if x-hulp < x-aantal 
then V(x-wacht) 
else V(x-weduit); 
P(x-wacht); 
end; 
x-aantal := x-aantal — 1; 
end; 
O; 
if x-aantal > 0 
then begin 
x-hulp := 0; 
V(x-wacht); 
end; 
else V(x-weduit); 


Deze implementatie gaat uit van een F IFO-ordening van de processen in de 
wachtrij voor een semafoor. 

_ Merk op dat deze implementatie vereist dat iedere keer dat een proces de 
kritieke regio verlaat, voor alle wachtende processen de waarde van de uitdruk- 
king B opnieuw wordt bepaald. Als diverse processen vertraagd zijn, omdat ze 
moeten wachten tot hun respectievelijke booleaanse uitdrukkingen waar worden, 
kan de overhead van dit opnieuw bepalen de code inefficiënt maken. Er zijn 
verschillende optimaliseringsmethoden die kunnen worden gebruikt om deze 
overhead terug te brengen. De lezer die daarin geïnteresserd is wordt verwezen 
naar Brinch Hansen [1972b] en Schmidt [1976] voor een bespreking van dit on- 
derwerp. 

De constructie van Hoare geeft de mogelijkheid dat processen alleen aan 
het begin van een kritieke regio vertraagd worden. Er zijn evenwel omstandighe- 
den waarbij ergens binnen de kritieke regio synchronisatievoorwaarden gesteld 
moeten worden. Deze waarneming heeft Brinch Hansen [1972b] op het spoor van 
de volgende regio-constructie gebracht: 
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region v 
do begin 
Ol; 
wachtaf(B); 
02; 
end; 


Wanneer een proces de kritieke regio binnenkomt voert het de opdracht O1 uit 
(O1 kan de nul-opdracht zijn). Dan bepaalt het de waarde van B. Als B waar is, 
wordt O2 uitgevoerd. Als B niet-waar is, geeft het proces de wederzijdse uitslui- 
ting op en moet het wachten tot B waar wordt en er geen ander proces zich 
bevindt in de regio die met v verbonden is. 

We lichten deze nieuwe constructie toe door een variant van het tweede 
lezers/schrijversprobleem te coderen. Het tweede lezers/ schrijversprobleem ver- 
eist dat, wanneer een schrijver eenmaal klaar is, hij zo spoedig mogelijk mag 
schrijven. Op deze wijze kan een lezer alleen zijn kritieke sectie binnenkomen als 
er geen schrijvers wachten of binnen zijn kritieke sectie zijn. 

De constructie van de voorwaardelijke kritieke regio wordt gecombineerd 
met de klasse-constructie die we eerder beschreven hebben. 


type lezer-schrijver = class 
var v: shared record 
nlezers, nschrijvers: integer; 
bezig: boolean; 
end; 


procedure entry open-lees; 


region v 
do begin | 
wachtaf(nschrijvers = 0); 
nlezers := nlezers + 1; 
end; 


procedure entry sluit-lees; 


region v 
do begin 
nlezers := nlezers — 1; 
end; | 
procedure entry open-schrijf; 
region v 
do begin 
nschrijvers := nschrijvers + 1; 
wachtaf((not bezig) and (nschrijvers = 0)); 
bezig := true; 


end; 
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procedure entry sluit-schrijf; 
region v 
do begin 
nschrijvers := nschrijvers — 1; 
bezig := false; 
end; 


begin 
bezig := false; 
nlezers := 0; 
nschrijvers := 0; 
end. 


Een lezer-proces moet een leesbewerking op het exemplaar van het bestand 
en bewerkingen op een exemplaar ls van de lezer-schrijver-klasse uitsluitend in 
de hieronder gegeven volgorde aanroepen: 


ls.open-lees; 

lees bestand 
lacshutt lacs: 

Evenzo moet een schrijver-proces bewerkingen aanroepen in deze volgorde: 

| ls.open-schrijf; 

schrijf bestand 

Is.sluit-schrijf. 

Het begrip klasse alleen kan echter niet de garantie geven dat aan deze 


volgorde de hand wordt gehouden. In het bijzonder kunnen de volgende gevallen 
voorkomen: | 


@ Een proces zou een bestand kunnen bewerken zonder eerst toegangspermissie 
daartoe te verkrijgen (door een rechtstreekse aanroep om van het bestand te 
lezen of ernaar te schrijven). 

@ Een proces zou het bestand wel eens niet meer kunnen vrijgeven nadat het er 
eenmaal toegang toe verkregen heeft. 

@ Een proces zou kunnen proberen een bestand vrij te geven waarom het nooit 
verzocht heeft. : | 

@ Een proces zou tweemaal om hetzelfde bestand kunnen verzoeken (zonder het 
eerst vrij te geven); enzovoort. 
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Let erop dat we nu moeilijkheden zijn tegengekomen die in wezen lijken op die 
welke ons in eerste instantie aanleiding gaven de constructie van de kritieke regio 
te ontwikkelen. Eerst moesten we ons zorgen maken over het juiste gebruik van 
semaforen. Nu zitten we met het probleem dat het compileerprogramma ons niet 
langer kan helpen met het juiste gebruik van bewerkingen die door de program- 
meur van de hogere programmeertaal gedefinieerd zijn. 

Eén manier om zeker te stellen dat de lezers en schrijvers werkelijk de hand 
houden aan de juiste volgorde van bewerkingen is dat we het gemeenschappelijk 
gebruikte bestand zelf binnen de lezer-schrijver-klasse opnemen. Bovendien zul- 
len we de volgende twee nieuwe externe procedures binnen de lezer-schrijver- 
klasse definiëren: 


procedure entry lees ( … ); 
begin 
open-lees; 


lees van het bestand 


sluit-lees; 
end; 


procedure entry schrijf ( … ); 
begin 
open-schrijf, 


schrijf naar het bestand 


sluit-schrijf, 
end; 


Nu zijn de procedures open-lees, sluit-lees, open-schrijf en sluit-schrijf lokaal bin- 
nen de klasse (dat wil zeggen, ze’ zijn geen ingangsprocedures) en kunnen niet 
van buitenaf aangeroepen worden. 

Deze oplossing geeft de zekerheid dat de gebruikersprocessen het bestand 
correct benaderen. Dit is echter niet erg bevredigend. We hebben aangenomen 
dat de programmeur die de lezer-schrijver-klasse heeft gecodeerd precies weet hoe 
de gebruikersprocessen toegang willen krijgen tot het bestand. Dit is geen redelij- 
ke veronderstelling, omdat het lezen en schrijven afhankelijk kan zijn van de 
toepassing. De ene gebruiker kan misschien vijf lees-bewerkingen achter elkaar 
willen doen, terwijl een andere gebruiker wellicht op een lees-bewerking een 
schrijf-bewerking wil laten volgen om het bestand bij te werken. 

In het algemeen is het niet aanvaardbaar het systeemelement in te kapselen 
in de module die het systeemelement indeelt. Van de programmeur van deze 
module kan en mag niet worden verlangd dat hij elk mogelijk gebruik van het 
systeemelement zal voorzien. 
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10.3.3 Monitoren 


In de voorgaande paragrafen hebben we de kritieke-regio-mechanismen voor 
processynchronisatie beschreven. We hebben dit mechanisme ook gecombineerd 
met het begrip klasse om een grotere mate van beveiliging te verkrijgen. Eén 
onaantrekkelijke eigenschap van deze combinatie was dat iedere procedure expli- 
ciet moest voorzien in zijn eigen synchronisatie. De wens de juiste synchronisatie 
automatisch te laten verlopen hebben Brinch Hansen [1973a] en Hoare [1974] 
ertoe gebracht een nieuwe taalconstructie te ontwikkelen, een monitor. 

Een monitor is een mechanisme dat het mogelijk maakt dat verschillende 
processen een veilig en effectief gebruik maken van abstracte gegevenstypen. De 
syntaxis van een monitor is identiek aan die van een klasse, behalve dat het sleu- 
telwoord class wordt vervangen door het sleutelwoord monitor. Het belangrijkste 
semantische verschil is dat de monitor wederzijdse uitsluiting garandeert; dat wil 
zeggen, er kan slechts één proces tegelijk binnen de monitor actief zijn. Deze 
eigenschap wordt gegarandeerd door de monitor zelf. Als gevolg daarvan hoeft 
de programmeur deze synchronisatiebeperking niet expliciet te coderen (zie 
figuur 10.3). 

De monitor, voorzover deze nu gedefinieerd is, lijkt in vele opzichten op de 
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Figuur 10.3 
Schematisch overzicht van een monitor 
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kritieke regio. Zoals we hebben gezien, is de kritieke regio niet krachtig genoeg 
voor het modelleren van synchronisatiemethoden, Daarom werd deze uitgebreid 
tot de voorwaardelijke kritieke regio. Evenzo hebben we bij monitoren extra 
synchronisatiemechanismen nodig. Deze mechanismen worden geleverd door de 
conditie-constructie (Engels: condition). Programmeurs die hun eigen synchro- 
nisatiemethode ’op maat’ moeten schrijven kunnen een of meer variabelen van 
het type condition definiëren: 


var x, y: condition; 


De enige bewerkingen die op een conditie-variabele kunnen worden aange- 
roepen zijn wacht en sein. Op deze wijze kan een conditie-variabele worden gezien 
als een abstract gegevenstype dat in deze twee bewerkingen voorziet (zie figuur 
10.4). De bewerking 


x.wacht; 


betekent dat de uitvoering van het proces dat deze bewerking aanroept wordt 
opgeschort tot een ander proces 


x.sein; 


aanroept. De x.sein-bewerking laat de uitvoering van precies één proces hervat- 
ten. Als de uitvoering van geen enkel proces is opgeschort, heeft de sein-bewer- 
king geen effect; dat wil zeggen, de toestand van x blijft dezelfde, alsof de bewer- 
king nooit was uitgevoerd. Vergelijk dit met de V-bewerking, die altijd invloed 
heeft op de toestand van de semafoor. 

Stel nu dat wanneer de x.sein-bewerking wordt aangeroepen door een pro- 
ces P, er met de conditie x een proces Q verbonden is waarvan de uitvoering is 
opgeschort. Het is duidelijk dat, als het proces Q waarvan de uitvoering is opge- 
schort toestemming krijgt zijn uitvoering te hervatten, het proces P dat de sein- 
bewerking doet moet wachten. Anders zouden P en Q beide tegelijk binnen de 
monitor actief zijn. Let er evenwel op dat in principe beide processen met hun 
uitvoering verder kunnen gaan. Er zijn twee mogelijkheden: 


a. P wacht totdat Q de monitor verlaat, of P wacht op een andere conditie. 
b. Q wacht totdat P de monitor verlaat, of Q wacht op een andere conditie. 


Er zijn redelijke argumenten aan te voeren om volgens (a) óf (b) te werk te gaan. 
Daar P al met zijn uitvoering in de monitor bezig was, lijkt keuze (b) redelijker. 
Als we echter proces P toestaan verder te gaan, is de ‘logische’ conditie waarop 
Q stond te wachten tegen de tijd dat Q zijn uitvoering hervat misschien niet 
langer geldig. 

Hoare heeft keuze (a) genomen, voornamelijk omdat het bovenstaande ar- 
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gument ten gunste van (a) direct vertaald kan worden in simpelere en elegantere 
bewijsvoeringen [Hoare 1974]. Brinch Hansen [1975] daarentegen koos voor een 
compromis. Wanneer P de sein-bewerking uitvoert verlaat hij onmiddellijk de 
monitor. Dit heeft tot gevolg dat de uitvoering van Q onmiddellijk hervat wordt. 
Deze methode is minder krachtig dan die van Hoare, daar een proces niet meer 
dan eenmaal tijdens één enkele procedure-aanroep kan seinen. Laten we deze 
ideeén verduidelijken door een monitor te schrijven die een binaire semafoor 
simuleert. 


type semafoor = monitor 
var bezig: boolean; 
nietbezig: condition; 


procedure entry P; 
begin 
if bezig then nietbezig.wacht; 
bezig := true; 
end; 


procedure entry V; 
begin 


bezig := false; 


nietbezig.sein; 
end; 
begin 
bezig := false; 
end. 


De booleaanse variabele bezig geeft de toestand van de semafoor aan. Wanneer 
de eerste P-bewerking wordt uitgevoerd, wordt de toestand van de semafoor op 
bezig gezet; als er nog meer P-bewerkingen worden geprobeerd, moeten deze 
processen wachten tot er een V-bewerking plaatsvindt. Merk op dat de V-bewer- 
king altijd bezig op niet-waar (false) zet. Als er een proces staat te wachten, zet 
de V-bewerking bezig onmiddellijk weer op waar (true). Als er geen proces wacht, 
blijft bezig niet-waar. 

Laten we nu een gecompliceerder voorbeeld bekijken, het probleem van de 
tafelende filosofen. We geven een impassevrije oplossing door alleen toe te staan 
dat een filosoof zijn rijststokjes oppakt indien beide beschikbaar zijn. Om deze 
oplossing te coderen moeten we onderscheid maken tussen drie toestanden waar- 
in een filosoof zich kan bevinden. Voor dit doel voeren we de volgende gegevens- 
structuur in: 


var toestand: array[0..4] of (denkend, hongerig, etend); 
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Figuur 10.4 
Monitor met conditievariabelen 


Filosoof i kan alleen toestand|i] = etend maken als zijn buren niet zitten te eten 
(dat wil zeggen, toestand{i-l mod 5] # etend en toestand{i + 1 mod 5] # etend). 
We moeten ook declareren: 


var zelf: array[0..4] of condition; 


waarin filosoof i zichzelf kan laten wachten wanneer hij hongerig is maar niet bij 
machte is de benodigde eetstokjes te verkrijgen. 

We zijn nu in staat onze oplossing te beschrijven. De verdeling van de eet- 
stokjes wordt bestuurd door de monitor: | 


type tafelende-filosofen = monitor 
var toestand: array[0..4] of (denkend, hongerig, etend); 
var zelf: array[0..4] of condition; 


procedure entry pakop (i: 0..4); 
begin 
toestand\i] := hongerig; 
test (i); 
if toestand|i] # etend then zelf{i].wacht; 
end; 
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procedure entry legneer (i: 0.4); 
begin 
toestand|i| := denkend; 
test (i—1 mod 5); 
test (i+ 1 mod 5); 
end; 


procedure entry test (k: 0.4); 
begin 
if toestand|k—1 mod 5] # etend 
and toestand|k] = hongerig 
and toestand|k + 1 mod 5] # etend 


then begin 
toestand|k| := etend; 
zelf{k].sein; 
end; 
end; 
begin 
for i := 0 to 4 


do toestand[il := denkend; 
end. 


Filosoof i moet de bewerkingen pakop en legneer aanroepen op een exem- 
plaar tf van de monitor tafelende-filosofen, en wel in deze volgorde: 


tf pakop(i); 
eet 
tf.legneer(ü); 


Gemakkelijk kan worden aangetoond dat deze oplossing garandeert dat 
geen twee buren tegelijk zitten te eten en dat er geen impasses zullen optreden. 
We merken echter op dat het mogelijk is dat een filosoof van honger omkomt. 
We zullen voor dit probleem geen oplossing geven, maar dit liever ter oefenin 
aan de lezer overlaten. | 

We willen nu een mogelijke implementatie van het monitor-mechanisme 
bekijken. Voor iedere monitor wordt een semafoor weduit (die de beginwaarde 1 
krijgt) geleverd. P(weduit) moet worden uitgevoerd voordat het proces de monitor 
ingaat, terwijl V(weduit) moet worden uitgevoerd na het verlaten van de monitor. 

Omdat een seinend proces moet wachten tot het proces waarvan de uitvoe- 
ring hervat wordt ofwel de monitor verlaat of wacht, wordt nog een semafoor 
volgende ingevoerd. Deze krijgt de beginwaarde 0, waardoor de uitvoering van de 
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seinende processen kan worden opgeschort. We moeten ook zorgen voor een inte- 
ger variabele volgende-aantal, om het aantal processen bij te houden waarvan de 
uitvoering is geblokkeerd door volgende. Zo zal iedere externe procedure F wor- 
den vervangen door 


P(weduit); 
rompcode van F; 


if volgende-aantal > 0 
then V(volgende) 
else V(weduit); 


Wederzijdse uitsluiting binnen een monitor is verzekerd. 

We kunnen nu beschrijven hoe conditievariabelen worden geimplemen- 
teerd. Voor iedere conditie x voeren we een semafoor x-sem en een integer varia- 
bele x-aantal in, die beide de beginwaarde 0 krijgen. De bewerking x.wacht kan 
nu geimplementeerd worden als: 


x-aantal := x-aantal + 1; 
if volgende-aantal > 0 
then V(volgende) 
else V(weduit); 
P(x-sem); 
x-aantal := x-aantal — 1; 


De bewerking x.sein kan worden geïmplementeerd als 


if x-aantal > 0 


then begin 
x-aantal := x-aantal + 1; 
V(x-sem); 
P(volgende); 
volgende-aantal := volgende-aantal — 1; 
end; 


Deze implementatie is van toepassing op de definitie van monitoren van zowel 
Hoare als Brinch Hansen. In sommige gevallen hoeft echter de implementatie 
niet algemeen geldig te zijn en is er een duidelijke verbetering in efficiéntie moge- 
lijk. We laten dit probleem ter oefening over aan de lezer. 

Let erop dat als een monitor M1 een andere monitor M2 aanroept, de we- 
derzijdse uitsluiting in M/ niet wordt losgelaten terwijl de uitvoering verder gaat 
in M2. Dit feit heeft twee gevolgen: 


@ Elk proces dat M/ aanroept zal gedurende deze tijd buiten M7 door weduit 
worden geblokkeerd. 
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@ Als het proces in een conditie-wachtrij in M2 wordt gezet, kan er een impasse 
optreden. 


Dit probleem wordt het probleem van de geneste monitoraanroepen genoemd. 

We richten onze aandacht nu op de volgorde waarin de uitvoering van 
processen wordt hervat. Dat wil zeggen, als de uitvoering van verschillende 
processen wordt opgeschort wegens conditie x en een x.sein-bewerking wordt 
uitgevoerd, welk proces is dan aan de beurt om zijn uitvoering te hervatten? Eén 
simpele methode ‘is: ’Wie-het-Eerst-Komt-het-Eerst-Maalt’ (WEKEM). Dus de 
uitvoering van het proces dat het langst staat te wachten wordt hervat. Er zijn 
echter vele omstandigheden waaronder zo’n simpele indelingsmethode niet goed 
genoeg werkt. Om deze reden voerde Hoare [1974] de constructie van het voor- 
waardelijk wachten in. Dit heeft de vorm 


x.wacht(c); 


waarin c een integer uitdrukking is waarvan de waarde wordt bepaald wanneer de 
wachtbewerking wordt uitgevoerd. De waarde van c, dat men een prioriteitsgetal 
noemt, wordt dan opgeslagen met de naam van het proces waarvan de uitvoering 
wordt opgeschort. Wanneer x.sein wordt uitgevoerd, wordt de uitvoering van het 
proces met het kleinste prioriteitsgetal hervat. 

Laten we dit mechanisme toelichten door een algoritme voor werkindeling 
te ontwikkelen dat een systeemelement in volgorde van Kortste-Job-Eerst (KJE) 
toewijst. We nemen aan dat elk proces bij zijn verzoek om toewijzing de maxima- 
le tijd opgeeft die dit proces denkt het systeemelement te zullen gebruiken. 

type KJV = monitor 
var bezig: boolean; 
x: condition; 
procedure entry verkrijg (tijd: integer); 
begin 
if bezig then x.wacht(tijd); 
bezig := true; 


end; 
procedure entry geefvrij; 
begin 
bezig := false; 
x.sein; 
end; 
begin 


bezig := false; 
end. 
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Een gecompliceerder voorbeeld, waarin we het C-AFTAST-algoritme voor 
magneetkop-werkindeling voor een schijf met n cilinders coderen (zoals beschre- 
ven in paragraaf 7.4), laten we hierna zien. 


type magneetkop = monitor 
var bezig: boolean; 
omhoog: condition; 
koppos, aantal: integer; 


procedure entry verkrijg (doel: integer); 
begin 
if bezig 
then if koppos < doel 
then omhoog.wacht(doel + aantal) 
else omhoog.wacht(doel + aantal + n); 
bezig := true; 
if doel < koppos 
then aantal := aantal + n; 
koppos := doel; 
end; 


procedure entry geefvrij; 
begin 
bezig := false; 
omhoog.sein; 
end; 


begin 
koppos := 0; 
aantal := 0; 
end. 


De variabele aantal dient ervoor de verzoeken in twee groepen te verdelen: 
die voor lagere en die voor hogere posities dan die van de magneetkop. Als de — 
kop op (cilinder) 50 staat, en we hebben een verzoek voor 75 en een ander voor 
25, dan wordt het verzoek voor 25 behandeld als een verzoek voor 25 +n. Aange- 
zien 75 < n, is ook 75 < 25 + n, en wordt aan het verzoek voor 75 het eerst 
voldaan. Uiteindelijk kan er voor de variabele aantal een overloop plaatsvinden. 
Dit probleem kan worden verholpen door extra code in te lassen om aantal terug 
te zetten op nul indien de wachtrij leeg is. 

Een proces dat toegang tot de schijf nodig heeft moet deze volgorde in acht 
nemen: 
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mk.verkrijg(i); 
benader cilinder i; 


mk.geefvrij; 


waarin mk een exemplaar van het type magneetkop is. Evenals in het lezers/ 
schrijversprobleem (zie paragraaf 10.3.2) kan het niet aanhouden van deze volg- 
orde tijdafhankelijke fouten tot gevolg hebben. Bovendien raakt het hele inde- 
lingsschema in de war als een proces cilinder i verkrijgt en vervolgens cilinder 
J # i gebruikt. Anders dan bij de opzet uit paragraaf 10.3.2, waarin we de lees- 
en schrijfbewerkingen in de monitor konden opnemen, kunnen we geen toegangs- 
bewerkingen tot de schijf binnen de indelingsmonitor magneetkop opnemen. Zou- 
den we dat doen, dan zou de indeling op de manier van het algoritme voor moni- 
tor-indeling werken en niet op de manier die we gecodeerd hebben. (Dit is een 
ander voorbeeld van het probleem van de geneste monitoraanroepen.) 

Om zekerheid te bieden dat de processen de juiste volgorde aanhouden, 
moeten we alle programma’s die gebruik maken van de magneetkop-monitor, en 
de daardoor bestuurde schijf, inspecteren. Er zijn twee condities die moeten wor- 
den nagegaan om de correcte werking van dit systeem vast te stellen. Ten eerste 
moeten gebruikersprocessen altijd hun aanroepen van de monitor in de juiste 
volgorde doen. Ten tweede moeten we er zeker van zijn dat een niet-meewerkend 
proces niet zomaar de toegangssluis van de wederzijdse uitsluiting zoals die door 
de monitor geboden wordt negeert en probeert het gemeenschappelijk gebruikte 
systeemelement rechtstreeks te benaderen zonder de toegangsprotocollen te ge- 
bruiken. Alleen als we zeker weten dat aan deze twee condities voldaan is, kunnen 
we garanderen dat er geen tijdafhankelijke fouten zullen optreden en dat het 
indelingsalgoritme dus niet verstoord wordt. 

Het is misschien mogelijk een klein statisch systeem hierop te inspecteren, 
maar voor een groot, of dynamisch, systeem is het niet goed doenlijk. Dit toe- 
gangsregulatieprobleem kan alleen worden opgelost door extra mechanismen 
waarover meer zal worden gezegd in hoofdstuk 11. 


10.4 Parallel-programmeertalen 


In deze paragraaf zullen we een kort overzicht geven van de bekendste talen die 
ingebouwde mechanismen voor procescommunicatie en -synchronisatie hebben. 
Deze talen verschillen in de manier waarop de elementaire communicatiefuncties 
worden ondersteund. Concurrent Pascal gebruikt het doorgeven van parameters, 
CSP gebruikt het doorgeven van berichten en Ada gebruikt een combinatie van 
beide methoden. 
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10.4.1 Concurrent Pascal 


Concurrent Pascal is een programmeertaal die is ontworpen voor het gestruc- 
tureerd programmeren van computerbesturingssystemen. De taal die ontwikkeld 
werd door Brinch Hansen [1975], is gebaseerd op de sequentiële taal Pascal 
[Wirth 1971]. Een van de opmerkelijkste aspecten van Concurrent Pascal is dat 
het modulaire opbouw van programma’s ondersteunt. Een systeem dat in deze 
taal geprogrammeerd is, is opgebouwd uit drie soorten modulen: processen, klas- 
sen en monitoren. | 

Processen zijn sequentieel en maken geen gemeenschappelijk gebruik van 
variabelen. Klassen zijn abstracte gegevenstypen; iedere klasse is voor één en 
slechts één proces toegankelijk. Communicatie tussen processen moet worden 
bewerkstelligd door monitoren. Monitoren in Concurrent Pascal lijken op de be- 
schrijving die we hebben gegeven in paragraaf 10.3.3, met de volgende twee ver- 
schillen: 


@ Conditievariabelen (in Concurrent Pascal wachtrijen genoemd) kunnen slechts 
één enkele ingang hebben. Als twee processen een geblokkeerde toestand op 
de conditievariabele proberen binnen te komen, treedt er een fout op. 

@ Wanneer een proces de sein-bewerking op een wachtrij aanroept, zorgt het 
ervoor dat de uitvoering van een geblokkeerd proces (zo dat er is) wordt hervat 
en verlaat het onmiddellijk de monitor. 


Deze verschillen hebben tot gevolg dat er door het compileerprogramma efficiën- 
tere code wordt gegenereerd. Ze beperken echter het soort programma’s dat we 
kunnen schrijven. Zo is het bijvoorbeeld niet mogelijk binnen één monitor-proce- 
dure tweemaal te seinen. 

Concurrent Pascal gaat aanzienlijk verder dan het alleen maar leveren van 
een mechanisme door middel waarvan een gegevenssegment veilig gemeenschap- 
pelijk gebruikt kan worden; het zal processen alleen de gemeenschappelijke toe- 
gang tot een gegevenssegment toestaan als dat segment binnen een monitor ge- 
declareerd is. De semantiek (betekenis) van de taal staat een programmeur niet 
toe dat hij een gemeenschappelijk gebruikt exemplaar van een gegevenstype op 
een andere manier declareert. 

Concurrent Pascal ondersteunt het ontwerpen van betrouwbare program- 
ma’s in belangrijke mate door de complexiteit van strategieën voor het beheer 
van systeemelementen te beperken. De taal staat geen recursieve procedures toe 
noch de definitie van recursieve gegevenstypen. Daarom kan al het interne geheu- 
gen op het moment van het vertalen statisch worden toegewezen. Alle program- 
macomponenten (exemplaren van processen, klassen en monitoren) worden door 
declaratie gecreëerd en zijn permanent. Tenslotte kunnen conditievariabelen 
(wachtrijen) slechts één enkele ingang hebben. 

Het nut van zo’n beperkend mechanisme dat in een hogere programmeer- 
taal is ingebed moet nog bewezen worden door de toepassing ervan in de praktijk. 
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Er zijn echter ten minste twee dwingende argumenten om het wel te gebruiken: 


@ Een programmeur die een systeem met behulp van Concurrent Pascal imple- 
menteert hoeft geen zorgen te hebben over tussentijdse fouten die soms veroor- 
zaakt worden door foutieve synchronisatiebeveiliging van gemeenschappelijk 
gebruikte variabelen. 

@ De eenvoud en standaardisering van een mechanisme voor het gemeenschap- 
pelijk gebruik van gegevens door processen die parallel worden uitgevoerd 
leidt waarschijnlijk tot een efficiënte systeemimplementatie. Inefficiëntie in 
systemen kan vaak worden teruggevoerd tot een gebrek aan conceptuele een- 
heid en helderheid in het eraan ten grondslag liggende ontwerp. 


Een ’Concurrent Pascal’-compileerprogramma is beschikbaar voor de PDP- 
11 computerserie en er zijn verschillende (kleine) besturingssystemen in die taal 
geschreven. 


10.4.2 CSP 


Communicerende Sequentiéle Processen (Engels: Communicating Sequential 
Processes; CSP) is een taalconstructie voor parallelprogrammering die geschikt 
is voor een netwerkomgeving van microcomputers met gedistribueerd geheugen 
[Hoare 1978]. De volgende begrippen staan centraal in de taal. 


@ Een CSP-programma bestaat uit een vast aantal sequentiéle processen die af- 
zonderlijke adresruimten beslaan. 

@ Communicatie en synchronisatie worden tot stand gebracht door middel van 
de invoer- en uitvoerconstructies. 

@ De sequentiéle besturingsstructuren zijn gebaseerd op Dijkstra’s beschermde 
commando’s [Dijkstra 1975]. 


Communicatie in CSP vindt plaats wanneer één proces een tweede proces 
benoemt als de bestemming voor uitvoer en het tweede proces het eerste benoemt 
als de bron voor invoer (u kunt de uitvoerbewerking zien als een zend en de 
invoerbewerking als een ontvang). De uitvoerwaarden worden van het eerste naar 
het tweede proces gekopieerd (het bericht wordt verzonden en ontvangen). Be- 
richten zijn alle van een bepaald type. De typen uit- en invoerberichten moeten 
met elkaar overeenstemmen wil er communicatie plaatsvinden. De overdracht 
van informatie vindt alleen plaats wanneer zowel het bron- als het bestemmings- 
proces respectievelijk de uit- en de invoercommando’s hebben aangeroepen. 
Daarom kan de verwerking van óf het bron- óf het bestemmingsproces worden 
opgeschort tot het andere proces klaar is met de desbetreffende uitvoer of invoer. 
(Dit is een comunicatiemethode met nul-capaciteit, zoals beschreven in paragraaf 
9.8.2.) De I/O-functie doet zowel als een communicatiemechanisme als een 


Hoofdstuk 10 Parallel-programmering 


synchronisatie-instrument dienst. De syntactische notatie van CSP-programma’s 
is uiterst beknopt en daarom wat onconventioneel. Hoewel we de notatie zouden 
kunnen veranderen om deze conventioneler te maken, hebben we ervoor gekozen 
de werkelijke syntaxis te geven zoals die werd gebruikt door Hoare. U moet zich 
maar op de ideeën die erachter schuilen concentreren en niet zozeer op de notatie. 

Bekijk, ter illustratie van deze ideeën, eens twee processen, producent en 
consument, die berichten willen uitwisselen. Het uitvoercommando in producent 
heeft de vorm: 


consument ! m (betekenis: zend m naar de consument). 
Het invoercommando in consument heeft de vorm: 
producent ? n (betekenis: ontvang n van de producent). 


De communicatie tussen deze twee processen komt tot stand wanneer beide 
processen de hierboven gedefinieerde I/O-commando’s aanroepen. Het effect is 
hetzelfde als dat van de toekenningsopdracht: 


n:= m; 


In dit voorbeeld kan de communicatie niet plaatsvinden als het type dat met de 
variabele m verbonden is niet overeenkomt met het type van n; dan zullen beide 
processen (voor altijd) wachten. Bovendien zal, als één van de communicerende 
processen eindigt, het daaropvolgende aanroepen door het andere proces van een 
berichtbewerking voortijdige beëindiging van dit proces tot gevolg hebben. 

In CSP wordt de sequentiële besturing gerealiseerd door het gebruik van 
Dijkstra’s ’bewaakte commando’-notatie. Een bewaakt commando heeft de 
vorm: 


<bewaking> — <commandolijst > 


Een bewaking bestaat uit een lijst van declaraties, booleaanse expressies en een 
invoercommando (elk daarvan is facultatief). Een bewaking mislukt als één van 
zijn booleaanse expressies de waarde false heeft, of als het proces dat in het in- 
voercommando genoemd wordt beëindigd is. Als een bewaking mislukt wordt 
het proces waarin deze opdracht is gedefinieerd voortijdig beëindigd. Als hij niet 
mislukt wordt de commandolijst uitgevoerd. Deze actie vindt alleen plaats nadat 
het invoercommando (indien dat er is) voltooid is. 

Bewaakte commando’s kunnen worden samengevoegd tot een toegevoegd 
commando dat de vorm heeft: 


[a > A [] G2 C [||] Ga > Cal 
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Een toegevoegd commando specificeert de uitvoering van één van zijn be- 
schermde-commando-elementen. Dus als alle bewakingen mislukken, mislukt 
ook het toegevoegde commando en wordt het proces voortijdig beëeindigd. Als 
er meer dan één beschermd commando met succes kan worden uitgevoerd, wordt 
een willekeurig beschermd commando uitgezocht om te worden uitgevoerd. 

Toegevoegde commando’s kunnen zo dikwijls mogelijk worden uitgevoerd 
door het gebruik van het repetitie-commando dat deze vorm heeft: 


1G > Ci [| & > I]...[] Go > Ca] 


Het toegevoegde commando wordt herhaaldelijk uitgevoerd zolang het niet mis- 
lukt. Wanneer al zijn bewakingen mislukken, mislukt het toegevoegde commando 
en wordt het repetitie-commando beëindigd. De besturing wordt dan overgedra- 
gen aan het volgende commando. 

Deze methode kan het best worden toegelicht aan de hand van een voor- 
beeld. Stel dat we een CSP-programma willen schrijven om het producent/con- 
sumentprobleem te implementeren met een begrensde buffer die uit tien elemen- 
ten bestaat. De tien buffers moeten ingekapseld worden in een CSP-proces be- 
grensde-buffer dat hierna wordt gedefinieerd. 


buffer: (0..9) artikel; 
in, uit: integer; 


in: = 0; 

uit : = 0; 

“lin < uit +10; producent ? buffer(in mod 10) 
> in:= in + |l; 


[| uit < in; consument ? meer() 
— consument ! buffer(uit mod 10); 
uit := uit + | 


Het producent-proces levert een artikel p aan het proces begrensde-buffer door 
uit te voeren: 


begrensde-buffer \ p; 


Het consument-proces ontvangt een artikel g van het proces begrensde-buffer 
door uit te voeren: 


begrensde-buffer \ meer(); 
begrensde-buffer ? q; 


De asymmetrie tussen de manier waarop het producent- en het consument-proces 
begrensde-buffer aanroepen is te wijten aan de eis dat in bewakingen alleen in- 
voercommando’s mogen optreden. 
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10.4.3 Ada 


Ada is een hogere programmeertaal, ontwikkeld op initiatief van het Amerikaan- 
se Ministerie van Defensie onder leiding van Jean Ichbiah [Ada 1980]. De taal 
kan voor conventionele programmering worden gebruikt alsook voor speciale 
behoeften op technisch gebied, zoals het onvertraagd aansturen van, of toezicht 
houden op, allerhande apparatuur. In deze paragraaf houden wij ons alleen bezig 
met die constructies van de taal die bedoeld zijn een voorziening te bieden om 
parallelprogramma’s te schrijven. Centraal in deze voorziening staat het begrip 
taak (Engels: task), een programmamodule die asynchroon wordt uitgevoerd (een 
taak kan worden gezien als een sequentieel proces, zoals dat gedefinieerd is in 
hoofdstuk 9). Taken kunnen communiceren en hun acties synchroniseren door 
middel van: 


@ De accept-opdracht (accepteer), die een combinatie is van procedure-aanroe- 
pen en berichtenoverdracht. 

@ De select-opdracht (selecteer), die een niet-deterministische besturingsstruc- 
tuur is, gebaseerd op Dijkstra’s *beschermde commando’-constructie. 


We gaan nu kort op deze twee taalconstructies in. 

Centraal in de communicatievoorziening staat de accept-opdracht, die de 
volgende vorm heeft. (Vierkante haken [] stellen een facultatief gedeelte voor, 
terwijl accolades {} een herhaling van nul of meer keer voorstellen.) 


accept <ingangsnaam> [<formele-parameterlijst >] 
[do <opdrachten> end;] 


De opdrachten binnen een accept-opdracht kunnen alleen worden uitgevoerd als 
een andere taak de ingangsnaam aanroept. Het aanroepen van een ingangsnaam 
is syntactisch hetzelfde als een procedure-aanroep. Op dit punt worden ook pa- 
rameters doorgegeven. Nadat de end-opdracht bereikt is, kunnen parameters te- 
ruggegeven worden en zijn beide taken vrij om verder te gaan. De uitvoering van 
óf de aanroepende taak óf de aangeroepen taak kan worden opgeschort tot de 
andere taak klaar is met zijn bijbehorende communicatie. Op deze manier func- 
tioneert de voorziening én als een communicatiemechanisme én als een synchro- 
nisatie-instrument. 

Keuzen tussen verschillende ingangaanroepen worden gemaakt met behulp 
van de select-opdracht, die gebaseerd is op Dijkstra’s idee van het beschermde 
commando. Om het kort te houden beschrijven wij een beperkte vorm van de 
select-opdracht, zonder vertraag- en beéindig-opdrachten (Engels respectievelijk: 
delay en terminate). De select-opdracht heeft de vorm: 
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De uitvoering van de select-opdracht gaat als volgt: 


Í. 


select 

[when <booleaanse expressie> => | 
<accept-opdracht> 
[<opdrachten>] 

{or [when <booleaanse expressies> = | 
<accept-opdracht> 
[<opdrachten>] 

[else <opdrachten>] 

end select; 


Van alle booleaanse expressies die in de select-opdracht voorkomen wordt de 
waarde bepaald. Iedere accept-opdracht waarvan de bijbehorende booleaanse 
expressie de waarde true heeft wordt gemerkt als open. Een accept-opdracht 
waaraan geen when-gedeelte voorafgaat wordt altijd als ’open’ aangemerkt. 


- Een open accept-opdracht kan alleen voor uitvoering worden geselecteerd als 


een andere taak een ingang heeft aangeroepen die met die accept-opdracht 
correspondeert. Als verschillende open opdrachten kunnen worden geselec- 
teerd, zal er willekeurig één worden uitgekozen om te worden uitgevoerd. Als 
er geen kan worden geselecteerd en er is een else-gedeelte, dan wordt het else- 
gedeelte uitgevoerd. Is er geen else-gedeelte, dan wacht de taak tot er een open 
opdracht kan worden geselecteerd. 


. Als er geen accept-opdracht open is en er is een else-gedeelte, dan wordt het 


else-gedeelte uitgevoerd. Anders wordt er een foutconditie gegenereerd. 


De accept-opdracht geeft een taak een mechanisme om op een van te voren 


bepaalde gebeurtenis in een andere taak te wachten. Anderzijds geeft de select- 
opdracht een taak een mechanisme om op een reeks gebeurtenissen te wachten 
waarvan de volgorde niet van tevoren voorspeld kan worden. 


Deze begrippen kunnen worden geïllustreerd aan de hand van het be- 


grensde-bufferprobleem van de producent/consument: 


task body begrensde-buffer is 
buffer: array [0..9] of artikel; 
in, uit: integer; 
aantal: integer; 
in: = 0; 
uit := 0; 
aantal := 0; 
begin 
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loop 
select 
when aantal < 10 > 
accept voegin (art: artikel) 
do buffer{in mod 10] := art end; 
in:= in + 1; 
aantal := aantal + 1; 
or when aantal > 0 > 
accept verwijder (art: out artikel) 
do art := buffer{uit mod 10] end; 
uit := uit + 1; 
aantal := aantal — |; 
end select; 
end; 
end. 


De producent-taak plaatst een artikel p in de begrensde-buffer door de uit- 
voering van: 


begrensde-buffer.voegin (p); 


De consument-taak krijgt een artikel g uit de begrensde-buffer-taak BB door uit 
te voeren: 


begrensde-buffer.verwijder (q); 


In tegenstelling tot CSP hebben we volledige symmetrie tussen de producent- 
en consument-taken. 


10.5 Samenvatting 


Het voordeel van hogere programmeertalen boven assembleertalen is dat ze de 
middelen verschaffen voor het schrijven van programma’s die eenvoudiger en 
gemakkelijker zijn te testen en te verifiëren, te wijzigen en over te brengen van 
de ene machine naar de andere. Programmeurs hoeven minder tijd te spenderen 
aan het ontwikkelen en testen van hun programma’s. 

Hogere programmeertalen die gebruikt kunnen worden voor het schrijven 
van parallelprogramma’s moeten een voorziening bieden voor: 
@ Modulaire opbouw. Drie soorten modulen zijn zeer gebruikelijk in een bestu- 

ringssysteem dat in een hogere programmeertaal geschreven is. 


O Processen zijn de actieve sequentiële modulen die asynchroon draaien. 
O Procedures vormen de elementaire programmastructuur voor het afscher- 
men van informatie. 


Opgaven 


O Abstracte gegevenstypen geven het mechanisme voor het inkapselen van ge- 
gevens en procedures. 


@ Synchronisatie. Een taal moet de middelen verschaffen om tijdafhankelijke 
fouten te weren. Men heeft diverse taalconstructies voorgesteld om deze pro- 
blemen het hoofd te bieden: 


O Kritieke regio’s kunnen worden gebruikt om wederzijdse uitsluiting op een 
veilige en efficiënte manier te implementeren. 

O Voorwaardelijke kritieke regio’s lijken op kritieke regio’s, maar kunnen wor- 
den gebruikt om willekurige synchronisatieproblemen op te lossen. 

O Monitoren leveren het synchronisatiemechanisme voor het gemeenschappe- 
lijk gebruik van abstracte gegevenstypen. 


De drie talen met ingebouwde mechanismen voor procescommunicatie en 
processynchronisatie waarnaar het meest wordt verwezen zijn: Concurrent Pas- 
cal, CSP en Ada. Deze talen verschillen in de manier waarop zij de elementaire 
communicatiefuncties ondersteunen. Concurrent Pascal gebruikt het doorgeven 
van parameters, CSP gebruikt het doorgeven van berichten en Ada gebruikt een 
combinatie van beide. 


Opgaven 


10.1 


10.2 


10.3 


10.4 


10.5 


10.6 


Zet P- en V-bewerkingen op een semafoor S om in gelijkwaardige kritie- 
ke regio’s zonder wachtlus. 


Laat zien dat monitoren, voorwaardelijke kritieke regio’s en semaforen 
alle gelijkwaardig zijn wat het soort synchronisatieproblemen betreft dat 
ermee kan worden geïmplementeerd. 


Breid de kaders-klasse van paragraaf 10.2.3 uit, zodat een proces m op- 
eenvolgende blokken kan verkrijgen. 


Schrijf een ‘begrensde buffer’-monitor waarin de buffers (of delen ervan) 
in de monitor zelf zijn ingebed. 


De strikte wederzijdse uitsluiting binnen een monitor maakt de ’begrens- 
de buffer’-monitor van opgave 10.4 voornamelijk geschikt voor kleine 
delen. 

a. Leg uit waarom. 

b. Bedenk een nieuwe opzet die geschikt is voor grotere delen. 


Schrijf een monitor voor schijf-werkindeling met gebruikmaking van het 
AFTAST-algoritme voor schijf-werkindeling. 


408 


10.7 


10.8 


10.9 


10.10 


10.11 


10.12 


10.13 


10.14 
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In het C-AFTAST-algoritme beschreven in paragraaf 10.3.3, kan de va- 

riabele ’aantal’, die als ’integer’ gedeclareerd is, overlopen daar deze al- 

tijd wordt opgehoogd maar nooit verlaagd. 

a. Wijzig het programma om zekerheid te bieden dat er geen overloop 
kan optreden. 

b. Stel dat we de overloop toelaten. Wat zullen de gevolgen zijn, en hoe 
kunnen deze worden geduld? 


Stel dat de sein-opdracht alleen als de laatste opdracht in een monitor- 
procedure kan vóórkomen. Hoe kan de implementatie die werd voorge- 
steld in paragraaf 10.3.3 worden vereenvoudigd? 


Schrijf een monitor voor het oplossen van het probleem van de tafelende 
filosofen. Verzeker u ervan dat uw oplossing impassevrij is. 


Schrijf een monitor voor het oplossen van het probleem van de slapende 
kapper (Opgave 9.21). 


Schrijf een monitor voor het oplossen van het probleem van de sigaret- 
tenrokers (Opgave 9.22). 


Een spool-verwerkingssysteem bestaat uit een invoer-proces /, een ge- 
bruikersproces G en een uitvoer-proces U dat gegevens uitwisselt door 
middel van twee ’begrensde buffer’-monitoren In en Uit (zie figuur 10.5). 
Schrijf een programma voor het implementeren van zo’n opzet, aanne- 
mende dat de lees- en schrijf-bewerkingen u toestaan van de kaartlezer 
te lezen en naar de afdrukeenheid te schrijven. 


Bekijk het voorbeeld van het oversteken van een rivier uit hoofdstuk 8. 
Schrijf een monitor voor het coördineren van het oversteken vanaf de 
twee tegenoverliggende oevers. Verzeker u ervan dat uw oplossing de 
garantie biedt dat verschillende personen vanaf dezelfde oever tegelijk 
kunnen oversteken en dat er geen impasses zullen optreden. 


Laat zien hoe het algoritme van Opgave 10.13 kan worden uitgebreid om 
ook verhongering te vermijden. 


kaartlezer printer 


Figuur 10.5 


Spool-verwerkingssysteem 


Opgaven 


10.15 Een bestand moet gemeenschappelijk worden gebruikt door een aantal 
verschillende processen, waarbij elk proces een uniek nummer heeft. Tot 
het bestand kunnen verschillende processen tegelijk toegang krijgen, 
mits aan de volgende beperking gevolg wordt gegeven: de som van alle 
unieke nummers verbonden met alle processen die tot het bestand toe- 
gang hebben moet op elk moment kleiner zijn dan n. Schrijf een monitor 
om de toegang tot het bestand te coördineren. 


10.16 Stel dat we de wacht/sein-constructie van monitoren vervangen door een 

enkele wachtaf(B)-constructie, waarin B een algemene booleaanse ex- 

pressie is die ervoor zorgt dat het proces dat deze constructie uitvoert 

moet wachten tot B waar wordt. 

a. Schrijf een monitor met gebruikmaking van deze opzet om het lezers/ 
schrijversprobleem te implementeren. 

b. Deze constructie kan in het algemeen niet efficiënt worden geïmple- 
menteerd; leg uit waarom niet. 

c. Welke beperkingen moeten op de wachtaf-opdracht worden aange- 
bracht, zodat deze doeltreffend kan worden geïmplementeerd. (Aan- 
wijzing: beperk de algemeenheid van B; zie Kessels [1977].) 


10.17 Hoewel een monitor wederzijdse uitsluiting verzekert, moeten de proce- 
dures herbetreedbaar zijn. Leg uit waarom. 


10.18 Beschouw een systeem dat bestaat uit processen Pi, P2, … , Pn, waarbij 
elk proces een uniek prioriteitsgetal heeft. Schrijf een monitor die drie 
identieke regeldrukkers aan deze processen toewijst, waarbij van de prio- 
riteitsgetallen gebruik gemaakt wordt om te beslissen over de volgorde 
van de toewijzing. 


10.19 Schrijf een monitor die een wekker implementeert die een programma 
dat de wekker aanroept in staat stelt zichzelf een aangegeven aantal tijds- 
eenheden (tikken) te vertragen. U mag ervan uitgaan dat er een echte 
klok in de apparatuur bestaat, die een procedure tik in uw monitor met 
regelmatige tussenpozen aanroept. 


Bibliografische verwijzingen 


Het begrip kritieke regio is te danken aan Hoare [1972b] en Brinch Hansen 
[1972b]. Het begrip voorwaardelijke kritieke regio werd voorgesteld door Hoare 
[1972b] en gegeneraliseerd door Brinch Hansen [1972b]. Een vergelijking van de 
begrippen semafoor, kritieke regio en voorwaardelijke kritieke regio wordt ge- 
geven door Brinch Hansen [1972a]. Algemene besprekingen zijn geschreven door 
Brinch Hansen [1973a, 1973b]. De kwestie van de efficiénte implementatie van 
de voorwaardelijke kritieke regio is onder de loep genomen door Schmid [1976]. 

Het begrip monitor werd ontwikkeld door Brinch Hansen [1973a]; het was 
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gegrond op het secretaresse-begrip van Dijkstra [1971]. Een volledige beschrijving 
van de monitor werd gegeven door Hoare [1974]. Een bespreking aangaande de 
verschillende manieren waarop het seinen kan worden geïmplementeerd werd 
gegeven door Howard [1976b]. Een uitbreiding van de monitor om de mogelijk- 
heid van automatisch seinen te bieden werd voorgesteld door Kessels [1977]. Im- 
plementatiekwesties werden besproken door Lister en Maynard [1976] en Schmid 
[1976]. 

Een ander synchronisatiebegrip, de co-routine, werd bedacht door Conway 
[1963] en toegelicht door Knuth [1973]. Deze constructie is voornamelijk geschikt 
voor een strikt verweven uitvoering van processen op één enkele processor en 
vormt het basisbegrip ’pijpen’ in het Unix-besturingssysteem. 

Abstracte gegevenstypen zijn voortgekomen uit het werk van Parnas [1971] 
over het afschermen van informatie en het begrip klasse van Simula 67 [Dahl et 
al. 1968]. Besprekingen over verschillende aspecten van taalnotaties zijn gegeven 
door Liskov en Zilles [1974, 1975]. 

Diverse hogere programmeertalen voor het schrijven van parallelle pro- 
gramma’s in een gecentraliseerde omgeving zijn de laatste tijd naar voren geko- 
men. Concurrent Pascal werd ontwikkeld door Brinch Hansen [1975] als een uit- 
breiding van het sequentiéle Pascal. De taal werd met succes gebruikt voor het 
schrijven van drie verschillende soorten besturingssystemen [Brinch Hansen 
1977]. Wirth [1977] ontwikkelde een andere parallel-programmeertaal, Modula 
genoemd, die eveneens een uitbreiding is van sequentieel Pascal. De taal heeft 
ook machine-afhankelijke voorzieningen, zodat met gebruikmaking van deze taal 
stuurprogramma’s voor randapparatuur kunnen worden geprogrammeerd. Ande- 
re talen zijn onder meer CSP/k [Holt et al. 1978], dat is gebaseerd op PL/I, 
Pascal-Plus [Welsh en Bustard 1979] en Mesa [Lampson en Redell 1980], dat 
gebruik maakt van het begrip monitor. 

Men heeft ook diverse hogere programmeertalen voor het schrijven van 
gedistribueerde programma’s voorgesteld. Communicating Sequential Processes 
(Communicerende Sequentiële Processen) [Hoare 1978], Distributed Processes 
(Gedistribueerde Processen) [Brinch Hansen 1978], Ada [Ada 1980], Plits [Feld- 
man 1979], MOD* [Cook 1980] en Synchronizing Resources (het synchroniseren 
van systeemelementen) [Andrews 1981] zijn onder meer de meest vermelde talen. 
Deze talen verschillen in het soort synchronisatie- en communicatievoorzienin- 
gen die geboden worden. 

Een belangrijk onderwerp van onderzoek op het gebied van parallel-pro- 
grammeertalen is het bewijzen van correctheid. Owicki en Gries [1976a, 1976b] 
en Lamport [1977] waren de eersten die zulke bewijssystemen ontwikkelden. 
Howard [1976a] gaf bewijsvoeringen voor Hoare-achtige monitoren. Owicki 
[1978] presenteerde een methode voor het verifiéren van parallelle programma’s 
die gemeenschappelijk gebruikte klassen bevatten in plaats van monitoren. Ander 
werk op dit gebied vindt men onder meer bij Apt et al. [1980], Levin en Gries 
[1981], Hoare [1981] en Misra en Chandy [1981]. 


I] 


BEVEILIGING 


De verschillende processen in een besturingssysteem moeten tegen elkaars activi- 
teiten worden beveiligd. Tot dat doel heeft men diverse mechanismen ontworpen, 
die kunnen worden gebruikt om te garanderen dat alleen die processen kunnen 
werken met bestanden, geheugensegmenten, de CVE en andere systeemfacilitei- 
ten, die door het besturingssysteem daartoe zijn geautoriseerd. 

De toegangsbesturing in een bestandssysteem bijvoorbeeld staat de gebrui- 
kers toe te bepalen wie tot hun bestanden toegang hebben en hoe. De apparatuur 
voor geheugenadressering zorgt ervoor dat een proces alleen binnen zijn eigen 
adresruimte kan worden uitgevoerd. Het tijdregister zorgt ervoor dat geen enkel 
proces de beschikking over de CVE kan krijgen zonder die ook weer vrij te geven. 
Tenslotte is het de gebruikers niet toegestaan hun eigen I/O te verzorgen, dit om 
de integriteit van de diverse randapparaten te beveiligen. 

In dit hoofdstuk zullen we het probleem van beveiliging nader onderzoeken 
en een aantal principes onderbrengen in een model voor de implementatie van 
beveiliging. 


11.1 Beveiliging: doelstellingen 


Met het geavanceerder worden van computersystemen en het toenemen van het 
aantal toepassingen, groeide ook de behoefte aan een goede beveiliging van hun 
integriteit. Beveiliging werd aanvankelijk gezien als een soort aanhangsel van 
multiprogrammeringssystemen, waarbij gebruikers (die toch niet altijd te ver- 
trouwen zijn) veilig gemeenschappelijk gebruik konden maken van dezelfde logi- 
sche naamruimte, zoals een bestandsadresboek, of dezelfde fysieke naamruimte, 
zoals het geheugen. Moderne ideeën over beveiliging gaan steeds meer in de rich- 
ting van het verhogen van de betrouwbaarheid van elk soort complex systeem 
dat gemeenschappelijk gebruik van systeemfaciliteiten kent. 

Met beveiliging duiden we het mechanisme aan voor het besturen van de 
toegang van programma’s, processen of gebruikers tot de faciliteiten die binnen 
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een computersysteem zijn gedefinieerd. Dit mechanisme moet een geschikt mid- 
del leveren om besturingsmaatregelen die moeten worden opgelegd te specifice- 
ren, én een paar middelen waarmee de handhaving daarvan kan worden verze- 
kerd. We maken onderscheid tussen beveiliging (Engels: protection) en veilig- 
heidszekerheid (Engels: security), die een vertrouwensgarantie inhoudt dat de 
integriteit van een systeem en zijn gegevens zal worden gewaarborgd. Veiligheids- 
zekerheid omvat veel meer dan beveiliging en zal daarom slechts globaal worden 
besproken (paragraaf 11.11). 

Er zijn diverse beweegredenen voor beveiliging. Het meest voor de hand 
ligt natuurlijk de noodzaak om te voorkomen dat een gebruiker van het systeem 
met kwade bedoelingen opzettelijk zondigt tegen een toegangsbeperking. Van 
algemener belang is echter de noodzaak de zekerheid te bieden dat elke program- 
macomponent die in een systeem actief is, de systeemfaciliteiten uitsluitend ge- 
bruikt op een manier die overeenstemt met het uitgestippelde beleid voor het 
gebruik van systeemfaciliteiten. Dit is een absolute eis voor een betrouwbaar 
systeem. 

Beveiliging kan de betrouwbaarheid verhogen door het ontdekken van la- 
tente fouten bij de koppelingen (Engels: interfaces) tussen de verschillende com- 
ponenten van het systeem. Het vroegtijdig ontdekken van fouten bij deze koppe- 
lingen kan dikwijls voorkómen dat een gezond subsysteem besmet wordt door 
een subsysteem dat niet goed werkt. Een niet-beveiligd systeemelement kan zich 
niet verweren tegen het gebruik (of misbruik) door een gebruiker die daartoe niet 
geautoriseerd is of zelfs domme dingen doet. Een op beveiliging gericht systeem 
levert de middelen om onderscheid te maken tussen geautoriseerd en ongeautori- 
seerd gebruik. 


11.2 Mechanismen en beleid 


Een computersysteem in de meest algemene zin kan worden gezien als een verza- 
meling processen en systeemfaciliteiten. Om de ordelijke en efficiënte werking 
van een systeem te garanderen, worden de processen onderworpen aan een beleid 
dat het gebruik van systeemfaciliteiten regelt. De rol van beveiliging in een com- 
putersysteem is het leveren van een mechanisme waarmee het beleid dat het ge- 
bruik van systeemfaciliteiten controleert kan worden afgedwongen. Zo’n beleid 
kan op een aantal manieren tot stand worden gebracht. Sommige beleidsregels 
zijn vastgelegd in het ontwerp van het systeem, terwijl andere worden gefor- 
muleerd door de personen die verantwoordelijk zijn voor het systeem. Nog weer 
andere beleidsregels worden vastgesteld door de gebruikers zelf die hun eigen 
bestanden en programma’s willen beveiligen. Een beveiligingssysteem moet de 
flexibiliteit bezitten om een aantal beleidsvormen af te dwingen die men aan het 
systeem kan opleggen. 

Het beleid voor het gebruik van systeemfaciliteiten kan afhangen van de 
toepassing en mettertijd wel eens gewijzigd worden. Daarom kan beveiliging niet 
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langer gezien worden als een zaak die alleen de ontwerper van een besturingssys- 
teem aangaat. Beveiliging moet ook voor de toepassingsprogrammeur beschik- 
baar zijn als een stuk gereedschap, zodat faciliteiten die in het leven zijn geroepen 
en ondersteund worden door een toepassingsgedeelte van het systeem, tegen mis- 
bruik kunnen worden beschermd. In dit hoofdstuk beschrijven we de bevei- 
ligingsmechanismen die het besturingssysteem moet leveren, zodat toepassings- 
programmeurs deze kunnen gebruiken bij het ontwerpen van hun eigen bevei- 
ligingsprogrammatuur. 

Eén heel belangrijk principe is de scheiding tussen het beleid en het me- 
chanisme. Mechanismen zijn ervoor om te bepalen hoe iets gedaan moet worden. 
Een beleid beslist wat gedaan wordt, niet hoe het wordt gedaan. De scheiding 
tussen beleid en mechanisme is heel belangrijk met het oog op de flexibiliteit. 
Het beleid kan nogal eens verschillen, afhankelijk van plaats of tijd. In het ergste 
geval zou elke verandering in een beleid vereisen dat ook het daarmee samenhan- 
gende machanisme wordt gewijzigd. Algemene mechanismen zouden wenselijker 
zijn, omdat een beleidswijziging in dat geval alleen zou vereisen dat enkele SyS- 
teemparameters of tabellen veranderd worden. 


11.3 Beveiligingsdomein 


Een computersysteem is een verzameling van processen en objecten. Met objecten 
bedoelen we zowel apparatuurobjecten (zoals de CVE, geheugensegmenten, prin- 
ters, programma's, kaartlezers en magneetbandeenheden) als programmatuurob- 
jecten (zoals bestanden, programma’s en semaforen). Elk object heeft een unieke 
naam dat het onderscheidt van alle andere objecten in het systeem, en toegang 
ertoe kan alleen worden verkregen via wel omschreven en zinvolle bewerkingen. 
Objecten zijn in wezen abstracte gegevenstypen. 

De bewerkingen die mogelijk zijn kunnen afhankelijk zijn van het object. 
Een CVE bijvoorbeeld kan alleen worden gebruikt om programma’s daarop uit 
te voeren. Van geheugensegmenten kunnen we zowel lezen als ernaar schrijven, 
terwijl van een kaartlezer alleen kan worden gelezen. Van magneetbanden kan 
worden gelezen, er kan naar worden geschreven en ze kunnen worden terugge- 
spoeld. Gegevensbestanden kunnen worden aangemaakt, geopend, gelezen, ge- 
schreven, gesloten en opgeheven, terwijl programmabestanden kunnen worden 
gelezen, geschreven en ook uitgevoerd. 

Uiteraard mag een proces alleen tot die systeemfaciliteiten toegang krijgen 
waartoe het geautoriseerd is. Bovendien moet het altijd slechts tot die systeem- 
faciliteiten toegang krijgen die het op dat moment nodig heeft om zijn taak te 
voltooien. Deze eis, die gewoonlijk wordt aangeduid als het alleen-waar-nodig 
(Engels: *need-to-know’) principe, is nuttig om de hoeveelheid schade die een 
verkeerd functionerend proces in het syteem kan aanrichten te beperken. Wan- 
neer bijvoorbeeld proces p procedure A aanroept, mag de procedure alleen toe- 
gang krijgen tot zijn eigen variabelen en de formele parameters die eraan worden 
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doorgegeven; het mag geen toegang krijgen tot alle variabelen van proces p. En 
neem het geval dat een proces p een compileerprogramma aanroept om een be- 
paald programmabestand te laten vertalen. Dit compileerprogramma mag geen 
toegang hebben tot elk willekeurig bestand, maar alleen tot een welbepaalde deel- 
verzameling bestanden (zoals het bronbestand, het uitlijstbestand, enzovoort) die 
betrekking hebben op het te compileren bestand. Omgekeerd kan het compileer- 
programma privé-bestanden hebben voor zijn boekhouding of voor het optimali- 
seren, waartoe het proces p geen toegang mag hebben. 

Om deze opzet te vergemakkelijken introduceren we het begrip beveiligings- 
domein. Een proces werkt binnen een beveiligingsdomein, dat aangeeft welke sys- 
teemfaciliteiten voor dat proces toegankelijk zijn. Ieder domein definieert een 
groep objecten en de soorten bewerkingen die voor elk object mogen worden 
aangeroepen. De bevoegdheid een bewerking op een object uit te voeren is een 
toegangsrecht. Een domein is een verzameling toegangsrechten, die elk bestaan 
uit een geordend paar <objectnaam, rechtengroep>>. Bevat domein D bijvoor- 
beeld het toegangsrecht < bestand B, lezen, schrijven>>, dan kan een proces dat 
in domein D wordt uitgevoerd zowel van B lezen als naar B schrijven; het kan 
echter geen enkele andere bewerking op dat object uitvoeren. 

Domeinen hoeven niet strikt gescheiden te zijn; zij kunnen gemeenschappe- 
lijke toegangsrechten hebben. Zo hebben we in figuur 11.1 drie domeinen: Dı, 
D en Ds. Het toegangsrecht < Ou, afdrukken> hebben D2 en D3 gemeenschap- 
pelijk, wat inhoudt dat een proces dat in één van deze twee domeinen werkt, 
object O4 kan afdrukken. Let erop dat een proces in domein Dı moet werken om 
van object O; te kunnen lezen en ernaar te schrijven. Daar staat tegenover dat 
alleen processen in domein D3 object Oı kunnen uitvoeren. 

Denk nog eens aan de standaard-dubbele-modus (monitor/ gebruiker-mo- 
dus) die we tegenkwamen bij onze bespreking van de uitvoering door het bestu- 
ringssysteem. Wanneer een proces aan zijn uitvoering bezig is in de monitor- 
modus, kan het bevoorrechte instructies uitvoeren en zo het volledige beheer over 
het computersysteem krijgen. Aan de andere kant kan het proces, als het wordt 
uitgevoerd in de gebruiker-modus, alleen niet-bevoorrechte instructies aanroe- 
pen. Het gevolg is dat het alleen binnen zijn van tevoren vastgestelde geheugen- 
ruimte kan worden uitgevoerd. Deze twee verwerkingswijzen (modi) beveiligen 
het besturingssysteem (dat wordt uitgevoerd in het monitor-domein) tegen de 


D2 D3 


D1 


<03,{Lezen,Schrijven} > 
<01,{Lezen,Schrijven} > 
<02,{Uitvoeren} > 


<02,{Schrijven}> - <04,{Afdrukken} > <01,{Uitvoeren} > 


<03,{Lezen}> 


Figuur 11.1 
Systeem met drie beveiligingsdomeinen 
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gebruikersprocessen (die draaien in het gebruikersdomein). In een besturingssys- 
teem met multiprogrammering zijn twee beveiligingsdomeinen niet voldoende, 
omdat de gebruikers ook ten opzichte van elkaar beveiligd willen zijn. Daarom 
is een uitgebreidere opzet nodig. 


11.4 Toegangsmatrix 


Ons beveiligingsmodel kan abstract worden gezien als een matrix, die we toe- 
gangsmatrix noemen. De rijen van de toegangsmatrix stellen domeinen voor, de 
kolommen objecten. Ieder element (of ingang) in de matrix bestaat uit een groep 
toegangsrechten. Omdat de kolom expliciet het object definieert, kunnen we de 
objectnaam uit het toegangsrecht weglaten. De ingang toegang(ij) definieert de 
groep bewerkingen die een proces dat wordt uitgevoerd in domein D; kan aanroe- 
pen voor object Oj. 

We willen dit toelichten aan de hand van de toegangsmatrix die figuur 11.2 
laat zien. Behalve de vier domeinen zijn er vijf objecten: drie bestanden (Bi, 
B2, Bs), één kaartlezer en één printer). Wanneer een proces in domein Dı wordt 
uitgevoerd, kan het de bestanden B: en B; lezen. Een proces dat wordt uitgevoerd 
in domein D4, heeft dezelfde rechten als in domein Dı. Bovendien kan het in de 
bestanden B, en B3 schrijven. Zoals u ziet zijn de kaartlezer en de printer alleen 
toegankelijk voor een proces dat wordt uitgevoerd in domein Do. 


11.5 Implementatie van de toegangsmatrix 
Hoe kan de toegangsmatrix op een doeltreffende manier worden geïmplemen- 


teerd? In het algemeen zal de matrix ’dun bevolkt’ zijn; dat wil zeggen, de meeste 
ingangen zullen leeg zijn. Hoewel er gegevensstructuurtechnieken voorhanden 


Figuur 11.2 
Toegangsmatrix 
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zijn voor het weergeven van dun bevolkte matrices, zijn deze niet erg bruikbaar 
voor dit soort toepassing wegens de manier waarop van de beveiligingsvoorzie- 
ning gebruik wordt gemaakt. 


11.5.1 Globale tabel 


De eenvoudigste implementatie van de toegangsmatrix is een globale tabel die 
bestaat uit een groep geordende triplets <domein, object, rechtengroep >. Steeds 
wanneer een bewerking M wordt uitgevoerd op een object O; binnen domein Di, 
wordt de globale tabel afgezocht op een triplet <D;, Oj, R>, waarbij M © Rx. 
Wordt zo’n triplet gevonden, dan mag de bewerking worden uitgevoerd; anders 
wordt een foutconditie gegenereerd. Deze implementatie kent verschillende na- 
delen. De tabel is gewoonlijk erg groot en kan daarom niet in het interne geheu- 
gen bewaard worden. Dit houdt in dat er extra I/O nodig is. Vaak worden 
virtuele-geheugentechnieken gebruikt om deze tabel te beheren. Bovendien is het 
moeilijk om profijt te trekken uit speciale groeperingen van objecten of domei- 
nen. Als bijvoorbeeld een bepaald object door iedereen gelezen kan worden, moet 
het in ieder domein een aparte ingang hebben. 


11.5.2 Toegangslijsten 


Iedere kolom in de toegangsmatrix kan als een toegangslijst voor één object wor- 
den geïmplementeerd, zoals dat beschreven werd in paragraaf 3.6.3. Uiteraard 
kunnen we de lege ingangen weglaten. De lijst die daarvan het resultaat is bestaat 
uit geordende paren < domein, rechtengroep >, die elk een domein met een niet- 
lege groep toegangsrechten voor dat object definiëren. 

Deze benadering kan eenvoudig worden uitgebreid om behalve een lijst ook 
een standaardgroep (Engels: default set) toegangsrechten te definiëren. Wanneer 
geprobeerd wordt op een object Oj in domein D; een bewerking M uit te voeren, 
zoeken we in de toegangslijst object O; op, waarbij we een ingang <Dj, R> 
willen vinden, zo dat M € Rx. Wordt deze ingang gevonden, dan staan we de 
bewerking toe; anders kijken we in de standaardgroep. Ook als M in de stan- 
daardgroep voorkomt staan we de bewerking toe. Anders wordt geen toegang 
verleend en treedt er een foutconditie op. Merk op dat het efficiënter kan zijn 
eerst in de standaardgroep en dan in de toegangslijst te zoeken. 


11.5.3 Beschikkingsrechtlijsten 


In plaats van de kolommen van de toegangsmatrix als toegangslijsten met de 
objecten te verbinden, kunnen we ook het verband leggen tussen rijen en domei- 
nen. Een beschikkingsrechtlijst (Engels: capability list) voor een domein is een lijst 
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met objecten en de bewerkingen die daarop zijn toegestaan. Een object wordt 
vaak voorgesteld door zijn fysieke naam of zijn adres, wat men een beschikkings- 
recht noemt. Om de bewerking M op object O; uit te voeren, roept het proces 
bewerking M op waarbij het beschikkingsrecht (in de vorm van een wijzer) voor 
object O; als een parameter wordt gespecificeerd. Alleen al het feit dat het proces 
het beschikkingsrecht bezit, betekent dat de toegang is toegestaan. 

De beschikkingsrechtlijst hoort bij een domein, maar is nooit direct toegan- 
kelijk voor een proces dat in dat domein wordt uitgevoerd. Eerder is het zo dat 
de beschikkingsrechtlijst zelf een beveiligd object dat door het besturingssysteem 
wordt onderhouden en voor de gebruiker alleen indirect toegankelijk is. Bevei- 
liging die op beschikkingsrecht berust steunt op het feit dat beschikkingsrechten 
nooit mogen worden overgebracht naar een adresruimte die direct toegankelijk 
is voor een gebruikersproces (waar zij gewijzigd zouden kunnen worden). Als alle 
beschikkingsrechten beveiligd zijn, is het object dat zij beschermen ook beveiligd 
tegen ongeautoriseerde toegang. 

Beschikkingsrechten werden oorspronkelijk voorgesteld als een soort bevei- 
ligde wijzers, om te voldoen aan de behoefte om systeemfaciliteiten te beveiligen, 
die men voorzag toen systemen met multiprogrammering uit de kinderschoenen 
groeiden. Het idee van een inherent beschermde wijzer (vanuit het gezichtspunt 
van een gebruiker van het systeem) verschaft een basis voor een beveiliging die 
kan worden uitgebreid tot op het niveau van de toepassingsprogramma’s. 

Om inherente beveiliging te geven moeten beschikkingsrechten wel onder- 
scheiden worden van andere soorten objecten en moeten ze geïnterpreteerd wor- 
den door een abstracte machine waarop programma’s op hoger niveau worden 
uitgevoerd. Beschikkingsrechten worden gewoonlijk van andere gegevens onder- 
scheiden op een van de volgende twee manieren: 


@ Elk object heeft een etiket (Engels: tag) om zijn type aan te duiden als een 
object met beschikkingsrecht óf met vrij toegankelijke gegevens. De etiketten 
zelf mogen niet direct toegankelijk zijn voor toepassingsprogramma’s. Men 
kan van ondersteuning door de apparatuur (hardware) of door programma- 
tuur binnen de apparatuur (firmware) gebruik maken om deze beperking af te 
dwingen. Hoewel slechts één bit nodig is om het onderscheid aan te geven 
tussen objecten met en zonder beschikkingsrecht, worden vaak meer bits ge- 
bruikt. Deze uitbreiding maakt het mogelijk dat alle objecten door de appara- 
tuur van een etiket dat hun type aanduidt worden voorzien. Zo kan de appara- 
tuur onderscheid maken tussen gehele getallen (integers), getallen in drijvende- 
kommavorm, wijzers, booleaanse variabelen, tekens (characters), instructies, 
objecten met beschikkingsrecht en variabelen die geen beginwaarde hebben 
gekregen. 

@ De andere mogelijkheid is dat de adresruimte die met een programma verbon- 
den is in twee delen kan worden verdeeld. Het ene deel is voor het programma 
toegankelijk en bevat zijn gewone gegevens en instructies. Het andere deel, dat 
de beschikkingsrechtlijst bevat, is alleen voor het besturingssysteem toeganke- 
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lijk. Een in segmenten verdeelde geheugenruimte (zie paragraaf 5.7) is heel 
bruikbaar om deze aanpak te ondersteunen. 


Men heeft verschillende beveiligingssystemen die op beschikkingsrecht zijn geba- 
seerd ontwikkeld. Deze zullen we in het kort beschrijven in paragraaf 11.8. 


11.5.4 Een slot/sleutelmechanisme 


De slot/sleutelmethode is een compromis tussen toegangslijsten en beschikkings- 
rechtlijsten. Elk object heeft een lijst unieke bitpatronen, die sloten heten. Op 
dezelfde wijze heeft elk domein een lijst unieke bitpatronen, die sleutels worden 
genoemd. Een proces dat in een domein wordt uitgevoerd kan alleen toegang tot 
dat object krijgen als dat domein een sleutel heeft die op een van de sloten van 
het object past. 

Evenals dat voor beschikkingsrechtlijsten het geval is moet de lijst met sleu- 
tels voor een domein door het besturingssysteem uit naam van dat domein wor- 
den beheerd. Het is de gebruikers niet toegestaan rechtstreeks de lijst met sleutels 
(of sloten) te inspecteren of te wijzigen. 


11.5.5 Vergelijking 


Toegangslijsten corresponderen direct met de behoeften van de gebruikers. Wan- 
neer gebruikers objecten creëren, kunnen zij specificeren welke domeinen tot de 
objecten toegang hebben en ook welke bewerkingen zijn toegestaan. Maar omdat 
de informatie over de toegangsrechten voor een bepaald domein niet binnen het 
domein is opgeslagen, is het moeilijk vast te stellen wat de toegangsrechten voor 
elk domein zijn. Bovendien moet iedere toegang tot het object worden gecontro- 
leerd, waarvoor het nodig is dat de toegangslijst wordt doorzocht. In een groot 
systeem met lange toegangslijsten kan dit zoekproces heel tijdrovend zijn. 

Beschikkingsrechtlijsten corresponderen niet rechtstreeks met de behoeften 
van de gebruikers; ze zijn echter nuttig om op te zoeken waar de informatie voor 
een bepaald proces zich bevindt. We hoeven dan geen lijst door te lopen om na 
te gaan of toegang is toegestaan. Het proces dat de toegang wenst moet zelf 
een beschikkingsrecht voor die toegang tonen. Dan hoeft het beveiligingssysteem 
alleen maar te controleren of het beschikkingsrecht geldig is. Herroeping van 
beschikkingsrechten kan evenwel heel inefficiënt zijn (paragraaf 11.7). 

Het slot/sleutelmechanisme is een compromis tussen deze twee methoden. 
Het mechanisme kan zowel doeltreffend als flexibel zijn, afhankelijk van de leng- 
te van de sleutels. De sleutels kunnen vrij van domein naar domein worden door- 
gegeven. Bovendien kunnen beschikkingsrecht-privileges op doeltreffende wijze 
worden herroepen door simpelweg enkele van de sleutels die bij het object horen 
te wijzigen (paragraaf 11.7). 


11.5 Implementatie van de toegangsmatrix 


De meeste systemen gebruiken een combinatie van toegangslijsten en lijsten 
voor beschikkingsrecht. Wanneer een proces voor het eerst probeert tot een ob- 
ject toegang te krijgen, wordt de toegangslijst doorzocht. Wordt de toegang niet 
verleend, dan treedt er een foutconditie op. Anders wordt er een beschikkings- 
recht gecreëerd en aan het proces gehangen. Verdere verwijzingen gebruiken het 
beschikkingsrecht om soepel en snel aan te tonen dat de toegang is toegestaan. 
Na de laatste toegang wordt het beschikkingsrecht vernietigd. Deze strategie 
wordt in het Multics-systeem en in het CAL-systeem gebruikt, in welke systemen 
zowel toegangslijsten als beschikkingsrechtlijsten dienst doen. 

Neem bijvoorbeeld een bestandssysteem. Bij ieder bestand hoort een toe- 
gangslijst. Wanneer een proces een bestand opent wordt de adresboekstructuur 
doorzocht om het bestand te vinden, het toegangsrecht wordt gecontroleerd en 
buffers worden toegewezen. Al deze informatie wordt opgeslagen in een nieuwe 
ingang in een bestandstabel die bij dit proces hoort. De open-bewerking retour- 
neert een index in die tabel voor het zojuist geopende bestand. Alle bewerkingen 
op het bestand vinden plaats door de index voor de bestandstabel op te geven. 
De ingang in de bestandstabel wijst daarbij naar het bestand en zijn buffers. 
Wanneer het bestand gesloten wordt, wordt de ingang in de bestandstabel opge- 
heven. Aangezien de bestandstabel door het besturingssysteem wordt onderhou- 
den, kan deze niet door de gebruiker verknoeid worden. Op deze manier zijn de 
enige bestanden waartoe de gebruiker toegang heeft de bestanden die geopend 
zijn. Daar de toegang wordt gecontroleerd wanneer het bestand geopend wordt, 
is beveiliging verzekerd. 

Let erop dat het recht tot toegang nog steeds bij iedere toegang gecontro- 
leerd moet worden en dat de ingang in de bestandstabel alleen voor de toegestane 
bewerkingen beschikkingsrecht heeft. Als een bestand geopend wordt om dit te 
lezen, wordt een beschikkingsrecht voor leestoegang in de bestandstabelingang 
geplaatst. Wordt een poging gedaan om te schrijven, dan wordt deze schending 
van de beveiliging ontdekt door de gewenste bewerking te vergelijken met het 
beschikkingsrecht in de bestandstabelingang. 


11.5.6 Beleid 


De methode van de toegangsmatrix levert ons het mechanisme voor het specifice- 
ren van diverse beleidsvormen. Het mechanisme bestaat uit het implementeren 
van de toegangsmatrix en het geven van de garantie dat de semantische eigen- 
schappen die we in paragraaf 11.4 hebben aangegeven inderdaad gelden. Meer 
in het bijzonder moeten we de zekerheid bieden dat een proces dat wordt uitge- 
voerd in domein D;, alleen toegang heeft tot die objecten die zijn aangegeven in 
rij i, en dan alleen nog voor die gevallen die zijn toegestaan volgens de ingangen 
van de toegangsmatrix. 

Beleidsbeslissingen aangaande beveiliging kunnen met behulp van de toe- 
gangsmatrix worden geïmplementeerd. Deze beleidsbeslissingen hebben onder 
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meer betrekking op de vraag welke rechten in de (i,/)-de ingang moeten voorko- 
men. We moeten ook beslissen in welk domein elk proces moet worden uitge- 
voerd. Deze laatste beleidsbeslissing wordt gewoonlijk genomen door het bestu- 
ringssysteem. 

De gebruikers beslissen gewoonlijk over wat er in de ingangen van de toe- 
gangsmatrix komt. Wanneer een gebruiker een nieuw object Oj; creëert, wordt de 
kolom O; aan de toegangsmatrix toegevoegd met de juiste beginwaarden voor de 
ingangen, zoals de persoon die het object creëert dat wil. De gebruiker kan beslis- 
sen om sommige rechten in sommige ingangen in kolom j te zetten en andere 
rechten in weer andere ingangen, al naar behoefte. 


11.6 Dynamische beveiligingsstructuren 


Het verband tussen een proces en een domein kan óf statisch zijn (als de groep 
systeemfaciliteiten die een proces ter beschikking staat gedurende de gehele 
levensduur van het proces niet verandert) óf dynamisch. Zoals u misschien had 
verwacht, dienen voor de problemen die inherent zijn aan het bepalen van dy- 
namische beveiligingsdomeinen meer weloverwogen oplossingen te worden be- 
dacht dan voor de eenvoudigere problemem in het statische geval. 

Als de relatie tussen processen en domeinen vastligt, en we willen vasthou- 
den aan het ’alleen-waar-nodig’ (need-to-know) principe, dan moeten we een me- 
chanisme hebben waarmee we de inhoud van een domein kunnen wijzigen. Een 
proces kan twee verschillende fasen van uitvoering kennen. Het kan bijvoorbeeld 
leestoegang nodig hebben in de ene fase en schrijftoegang in de andere. Als de 
toegangsmatrix statisch is, moeten we het domein zo definiëren dat het zowel 
lees- als schrijftoegang toelaat. Deze regeling geeft echter meer rechten dan er in 
elk van de twee fasen nodig zijn, omdat we leestoegang hebben in de fase waarin 
alleen schrijftoegang nodig is, en omgekeerd. Het ’alleen-waar-nodig’ principe 
wordt dus geweld aangedaan. We moeten ervoor zorgen dat de inhoud van de 
toegangsmatrix gewijzigd kan worden, zodat deze altijd de noodzakelijke mi- 
nimumtoegangsbehoeften voor het proces en zijn domein weerspiegelt. 

Is de relatie dynamisch, dan is er een mechanisme beschikbaar dat een 
proces de mogelijkheid biedt van het ene domein naar het andere om te schake- 
len. We zouden ook kunnen wensen dat de inhoud van een domein veranderd 
kan worden. Kunnen we de inhoud van een domein niet veranderen, dan kunnen 
we altijd nog hetzelfde effect bereiken door een nieuw domein te creëren met de 
veranderde inhoud en dan over te schakelen naar dat nieuwe domein. 

Het is duidelijk dat zowel de statische als de dynamische opzet een strakke 
besturing vereisen. Anders zou het beveiligingsbeleid in de war geschopt kunnen 
worden. Gelukkig hebben we al een mechanisme om die besturing te implemen- 
teren: de toegangsmatrix. Wanneer we een proces omschakelen van het ene do- 
mein naar het andere, voeren we een bewerking (omschakeling) uit op een object 
(het domein). We kunnen domeinomschakeling besturen door in de objecten van 
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de toegangsmatrix ook domeinen op te nemen. Evenzo voeren we, wanneer we 
de toegangsmatrix wijzigen, een bewerking uit op een object: de toegangsmatrix. 
Daar elke ingang in de toegangsmatrix apart gewijzigd kan worden, moeten we 
in feite iedere ingang in de toegangsmatrix beschouwen als een object dat bevei- 
ligd moet worden. 

Nu hoeven we alleen maar te letten op de bewerkingen die mogelijk zijn op 
deze nieuwe objecten (domeinen en de toegangsmatrix) en op de manier waarop 
we willen dat processen in de gelegenheid zijn deze bewerkingen uit te voeren. 

Processen moeten in staat zijn van het ene domein naar het andere om te 
schakelen. Domeinomschakeling van domein D; naar domein D; is dan en alleen 
dan toegestaan als het toegangsrecht omschakelen n toegang(i,j). Zo kan in figuur 
11.3 een proces dat wordt uitgevoerd in domein D2 omschakelen naar domein D3 
of domein Ds. Een proces in domein D4 kan omschakelen naar Di en een proces 
in domein Dı kan omschakelen naar domein Ds. 

Het toestaan van het gereguleerd veranderen van de inhoud van de ingan- 
gen van de toegangsmatrix vereist drie extra bewerkingen: kopiëren, (wisselen 
van) eigenaar en besturen. 

De bevoegdheid een toegangsrecht te kopiëren van het ene domein (rij) van 
de toegangsmatrix naar een ander wordt aangegeven door achter het toegangs- 
recht een sterretje (*) te zetten. Het kopieerrecht staat alleen toe dat het toegangs- 
recht wordt gekopieerd binnen de kolom (dat wil zeggen, voor het object) waar- 
voor het recht is gedefinieerd. In figuur 11.4a bijvoorbeeld kan een proces dat | 
wordt uitgevoerd in domein D2 de leesbewerking kopiéren naar elke andere in- 
gang die bij bestand B2 hoort. Zo kan de toegangsmatrix van figuur 11.4a worden 
gewijzigd in de toegangsmatrix van figuur 4b. 

Op deze methode bestaan twee varianten: 

a. Wanneer een recht wordt gekopieerd van toegang(i,/) naar toegang(k,/), wordt 
dit recht uit toegang(i,j) verwijderd. Dit is eigenlijk niet het kopiëren maar het 


overdragen van een recht. 
Object 
j Kaart- 
Domein B1 lezer 
Omscha- 
kelen 


ne A 
Lezen Af- 
druk- . Omscha- | Omscha- 
ken kelen kelen 


Figuur 11.3 
Toegangsmatrix van figuur 11.2 met domeinen als objecten 
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TC 

ee | omm | er | mee 

ete 
(a) 


NC |_| eee 


ces eee 


(b) 


Figuur 11.4 
Toegangsmatrix met kopieerrechten 


b. De verbreiding van het kopieerrecht kan beperkt zijn. Dat wil zeggen, wanneer 
het recht R* van toegang(i,j) wordt gekopieerd naar toegang(k,j), wordt alleen 
het recht R (niet R*) verworven. Een proces dat wordt uitgevoerd in domein 
D kan niet het recht R verder kopiëren. 


Het kan zijn dat een systeem slechts één van deze drie kopieerrechten kiest, of het 
kan alle drie de rechten leveren door deze als afzonderlijke rechten te identifi- 
ceren: kopiëren, overdragen en beperkt-kopiëren. 

Het kopieerrecht geeft een proces de gelegenheid een aantal rechten uit een 
ingang in de ene kolom te kopiëren naar een andere ingang in dezelfde kolom. 
We hebben ook een mechanisme nodig voor het laten toevoegen van nieuwe rech- 
ten en het laten verwijderen van sommige rechten. Het eigenaarsrecht reguleert 
deze bewerkingen. Als toegang(ij) onder meer het eigenaarsrecht bevat, kan een 
proces dat in domein D; wordt uitgevoerd elk recht in elke ingang van kolom j 
toevoegen en verwijderen. In figuur 11.5a is bijvoorbeeld Dı de eigenaar van Bi 
en kan dus een proces in D; elk geldig recht in kolom B, toevoegen en tenietdoen. 
Evenzo is domein D2 de eigenaar van B2 en Bs, zodat een proces in D2 elk geldig 
recht binnen deze twee kolommen kan toevoegen en verwijderen. De toegangs- 
matrix in figuur 11.5a kan derhalve worden gewijzigd in de toegangsmatrix in 
figuur 11.5b. 

De kopieer- en eigenaarsrechten staan een proces toe de ingangen binnen 
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ae ee 
Be bask 


Lezen* Lezen* 
Eigenaar Eigenaar 
Schrijven* 


Eigenaar Lezen* 
Lezen* Eigenaar 
Schrijven* Schrijven* 


Figuur 11.5 
Toegangsmatrix met eigendomsrechten 


een kolom te wijzigen. Er is ook een mechanisme nodig om ingangen in een rij 
te veranderen. Het besturingsrecht is alleen van toepassing op domeinobjecten. 
Als toegang(i j) het besturingsrecht bevat, kan een proces dat in domein D; wordt 
uitgevoerd elk toegangsrecht van rij j verwijderen. Stel bijvoorbeeld dat we in 
figuur 11.3 het besturingsrecht in toegang(D2, D4) zetten. Dan zou een proces dat 
in domein D2 wordt uitgevoerd domein Ds kunnnen wijzigen zoals is aangegeven 
in figuur 11.6. 

Deze bewerkingen op de domeinen en de toegangsmatrix zijn op zichzelf 
niet zo bijster belangrijk. Belangrijker is dat ze illustreren dat het model toestaat 
dynamische beveiligingseisen te implementeren en te besturen. Nieuwe objecten 
en nieuwe domeinen kunnen dynamisch worden gecreëerd en in het toegangsma- 
trixmodel worden opgenomen. We hebben evenwel alleen nog maar aangetoond 
dat het basismechanisme voorhanden is; de beleidsbeslissingen aangaande de 
vraag welke domeinen toegang moeten hebben tot welke objecten, en op welke 
manier, moeten worden genomen door de systeemontwerpers en de gebruikers. 
De toegangsmatrix is een algemeen mechanisme dat niet een speciaal bevei- 
ligingsbeleid vereist. 
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Figuur 11.6 | 
Gewijzigde toegangsmatrix van figuur 11.3 


Het dynamische-beveiligingsmodel levert een mechanisme voor het oplos- 
sen van het toegangsbesturingsprobleem van paragraaf 10.3.3. We zagen dat mo- 
nitoren niet toereikend waren om gebruikers hun eigen systeemfaciliteiten te la- 
ten creëren en het gebruik daarvan te besturen. Zouden de systeemfaciliteiten in 
een monitor ingebed zijn, dan zou hun gebruik bestuurd worden door het inge- 
bouwde monitor-werkindelingsbeleid; de gebruikers zouden hun eigen werkin- 
delingsbeleid niet kunnen opleggen. Bovendien verhindert het feit dat slechts één 
proces tegelijk in een monitor kan worden uitgevoerd de gelijktijdige toegang tot 
systeemfaciliteiten die nodig is voor de lezers in het lezers/schrijversprobleem. 

Willen we deze problemen kunnen oplossen, dan moeten de systeemfaci- 
liteiten zich buiten de monitor bevinden. Nu hebben we echter niet het beheer 
over het gebruik van de systeemfaciliteiten. Om dit beheer te leveren wordt voor 
ieder systeemelement een monitor, beheerder geheten, gecreëerd. Deze beheerder 
bestuurt de toegang tot de systeemfaciliteiten en verzorgt de werkindeling daar- 
voor. Om een systeemfaciliteit te gebruiken roept een proces eerst de beheerder 
aan, die de gebruiker een beschikkingsrecht voor het systeemelement teruggeeft. 
Wanneer het proces beëindigd wordt, geeft het dit beschikkingsrecht aan de be- 
heerder terug, die dit dan aan andere wachtende processen kan toewijzen, over- 
eenkomstig zijn eigen algoritme voor werkindeling. Op die wijze bieden beschik- 
kingsrechten een oplossing voor het probleem van het toegangsbesturingspro- 
bleem van paragraaf 10.3.3. Een verkeerd functionerend gebruikersproces kan 
alleen beperkte schade aanrichten voor andere processen; het kan een beschik- 
kingsrecht verkrijgen tot een gemeenschappelijk gebruikt systeemelement en wei- 
geren dit weer vrij te geven. Voor deze omstandigheid bestaat, ten koste van 
enige extra overhead in de uitvoering, een remedie: het voortijdig herroepen van 
beschikkingsrechten. 
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In een dynamisch beveiligingssysteem kan het soms noodzakelijk zijn toegangs- 
rechten tot objecten die door een aantal verschillende gebruikers gemeenschappe- 
lijk gebruikt worden te herroepen. Nu kunnen er over dit herroepen een aantal 
vragen opkomen: 


© Onmiddellijk/na enige tijd. Vindt herroeping onmiddellijk plaats of na enige 
tijd? Als herroeping enige tijd later plaatsvindt, kunnen we dan te weten ko- 
men wanneer het dan wel plaatsvindt? 

@ Selectief/algemeen. Wanneer een toegangsrecht tot een object herroepen 
wordt, betreft dat dan alle gebruikers die tot dat object toegangsrecht hebben, 
of kunnen we een groep gebruikers uitkiezen waarvan de toegangsrechten 
moeten worden herroepen? 

@ Gedeeltelijk/geheel. Kan een gedeelte van de rechten die met een object ver- 
bonden zijn worden herroepen, of moeten we alle toegangsrechten voor dit 
object herroepen? 

@ Tijdelijk/permanent. Kan de toegang permanent worden herroepen (dat wil 
zeggen dat het herroepen toegangsrecht nooit meer beschikbaar komt), of kan 
toegang herroepen en later weer verkregen worden? 


Met de methode van de toegangslijst is herroeping heel gemakkelijk. De 
toegangslijst wordt doorzocht op de toegangsrechten die herroepen moeten wor- 
den; deze worden dan uit de lijst verwijderd. De herroeping vindt onmiddellijk 
plaats en kan algemeen of selectief zijn, geheel of gedeeltelijk en permanent of 
tijdelijk. 

Beschikkingsrechten vormen echter een veel moeilijker probleem bij herroe- 
ping. Aangezien de beschikkingsrechten over het gehele systeem verspreid zijn, 
moeten we ze eerst vinden voordat we ze kunnen herroepen. Er zijn een aantal 
verschillende manieren om herroeping bij gebruik van beschikkingsrechten te im- 
plementeren, zoals: 


@ Opnieuw verwerven. Elk domein raakt periodiek zijn beschikkingsrechten 
kwijt. Wil een proces een beschikkingsrecht gebruiken, dan is het mogelijk dat 
het ontdekt dat dit beschikkingsrecht ongedaan gemaakt is. Het proces kan 
dan proberen het beschikkingsrecht opnieuw te verwerven. Als de toegang her- 
roepen is, zal het proces niet in staat zijn het beschikkingsrecht opnieuw te 
verkrijgen. 

@ Achterwaartse wijzers. Bij ieder object wordt een lijst met wijzers bijgehouden 
die wijzen naar alle beschikkingsrechten die bij dat object horen. Wanneer 
herroeping vereist is, kunnen we deze wijzers volgen en de beschikkingsrech- 
ten, waar nodig, wijzigen. Deze methode heeft men gevolgd in het Multics- 
systeem. Dit is een heel algemene, maar wel erg kostbare implementatie. 

@ Indirecte verwijzing. De beschikkingsrechten wijzen niet rechtstreeks naar de 
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objecten, maar wijzen in plaats daarvan indirect [Redell 1974]. Elk beschik- 
kingsrecht wijst naar een unieke ingang in een globale tabel, die op zijn beurt 
naar het object wijst. Herroeping wordt dan geimplementeerd door de globale 
tabel te doorzoeken op de gewenste ingang en deze ongeldig te maken. Wordt 
daarna een toegangspoging ondernomen, dan ontdekken we dat het beschik- 
kingsrecht naar een ongeldige tabelingang wijst. Tabelingangen kunnen zon- 
der bezwaar weer voor andere beschikkingsrechten worden gebruikt, omdat 
zowel het beschikkingsrecht als de tabelingang de unieke naam van het object 
bevatten. Het object voor een beschikkingsrecht en de bijbehorende tabelin- 
gang moeten met elkaar overeenkomen. Deze opzet werd gevolgd in het CAL- 
systeem. Het geeft echter niet de mogelijkheid van selectieve herroeping. 
Sleutels. Een sleutel is een uniek bitpatroon dat met elk beschikkingsrecht kan 
worden verbonden. Deze sleutel wordt gedefinieerd op het moment dat het 
beschikkingsrecht wordt gecreéerd; hij kan door het proces dat dat beschik- 
kingsrecht bezit niet worden gewijzigd en ook niet worden geinspecteerd. Er 
kan een met ieder object verbonden hoofdsleutel worden gedefinieerd; deze 
sleutel kan weer worden vervangen met behulp van de stel-sleutel-in-bewer- 
king. Wanneer een beschikkingsrecht wordt gecreéerd, wordt de huidige waar- 
de van de hoofdsleutel met het beschikkingsrecht verbonden. Wanneer het 
beschikkingsrecht wordt uitgeoefend, wordt zijn sleutel vergeleken met de 
hoofdsleutel. Als de sleutels overeenstemmen mag de bewerking doorgaan; 
anders treedt er een foutconditie op. Herroeping geeft aan de hoofdsleutel 
-een nieuwe waarde door middel van de stel-sleutel-in-bewerking, waadoor alle 
vorige beschikkingsrechten voor dit object ongeldig worden gemaakt. 

Let erop dat deze methode geen selectieve herroeping toelaat, omdat er 
met elk object slechts één hoofdsleutel verbonden is. Zouden we een lijst met 
sleutels met elk object verbinden, dan kan selectieve herroeping worden geïm- 
plementeerd. Tenslotte kunnen we alle sleutels in één globale tabel onderbren- 
gen. Een beschikkingsrecht is alleen geldig als zijn sleutel overeenstemt met 
een sleutel in de globale tabel. Herroeping wordt dan geïmplementeerd door 
de passende sleutel uit de tabel te verwijderen. Met deze methode kan een 
sleutel met verschillende objecten worden verbonden en kunnen verschillende 
sleutels verbonden worden met elk object. Dit geeft maximale flexibiliteit. 

In methoden die met sleutels werken mogen de bewerkingen van het 
definiëren van sleutels, het invoegen van sleutels in lijsten of het verwijderen 
daaruit, niet aan alle gebruikers ter beschikking staan. In het bijzonder zou 
het redelijk zijn alleen de eigenaar van een object toe te staan de sleutels daar- 
van in te stellen. Deze keuze is echter een beleidsbeslissing die in het bevei- 
ligingssysteem geïmplementeerd kan zijn, maar die niet door het beveiligings- 
systeem genomen dient te worden. 
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Tot nu toe hebben we de vraag vermeden wat een domein precies is. Een domein 
is een abstract begrip dat op diverse manieren gerealiseerd kan worden: 


@ Een domein kan gedefinieerd worden voor elke gebruiker. De groep objecten 
waartoe toegang kan worden verkregen hangt dan af van de identiteit van 
de gebruiker. Domeinomschakeling vindt plaats wanneer er een wisseling van 
gebruiker plaatsvindt, in het algemeen wanneer een gebruiker zich afmeldt 
Cuitlogt’) en een andere gebruiker zich aanmeldt Cinlogt”). 

@ Elk proces kan een domein zijn. In dit geval beschrijft iedere rij in de toegangs- 
matrix tot welke objecten dat proces toegang heeft en ook welke bewerkingen 
zijn toegestaan. Domeinomschakeling komt ermee overeen dat het ene proces 
een bericht naar een ander proces stuurt en dan op antwoord wacht. 

@ Elke procedure kan een domein zijn. Iedere rij in de toegangsmatrix beschrijft 
dan tot welke objecten die procedure toegang heeft. In deze situatie veroor- 
zaken procedure-aanroepen domeinomschakeling. 


In deze paragraaf geven we een kort overzicht van de bekendste bevei- 
ligingssystemen. Deze systemen verschillen in complexiteit en in het soort beleid 
dat daarin geïmplementeerd kan zijn. 


11.8.1 Unix 


In het Unix-systeem [Ritchie en Thompson 1974] is het beveiligingssysteem fun- 
damenteel rond het bestandssysteem gebouwd. Met ieder bestand zijn drie bevei- 
ligingsvelden verbonden, die corresponderen met de eigenaar, de groep gebrui- 
kers en een universele classificatie. Elk veld bestaat uit drie bits: /, s en u. 
De /-bit bestuurt de leestoegang, s de schrijftoegang en u de uitvoeringstoegang. 
Een domein is in Unix verbonden met de gebruiker. 

Domeinomschakeling staat gelijk met het tijdelijk veranderen van de ge- 
bruikersnaam. Deze verandering wordt door het bestandssysteem als volgt be- 
werkstelligd. Met iedere gebruiker worden een gebruikersnaam en een domeinbit 
verbonden. Wanneer een gebruiker (met gebruikersnaam = A) een bestand begint 
_ ult te voeren waarvan B de eigenaar is, terwijl de domeinbit van B aanstaat, wordt 
de gebruikersnaam gelijkgemaakt aan B. Wanneer de verwerking het bestand ver- 
laat wordt de gebruikersnaam weer gelijkgemaakt aan A. 


11.8.2 Multics 


In het Multics-systeem staan in het beveiligingssysteem het bestandssysteem en 
een ringstructuur centraal. De beveiligingsvoorziening voor het bestandssysteem 
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Ring 0 


Ring 1 


Ring N—1 


Figuur 11.7 
De ringstructuur van Multics 


werd beschreven in paragraaf 3.6.3. Kort gezegd: met ieder bestand is een toe- 
gangslijst, evenals een eigenaarsveld en een universeel toegangsveld verbonden. 

De beveiligingsdomeinen zijn in Multics hiërarchisch in een ringstructuur 
georganiseerd. Elke ring correspondeert met één domein (figuur 11.7). De ringen 
zijn genummerd van 0 tot en met 7. Als D; en D; twee domeinringen voorstellen, 
en j < i, dan is D; een deelverzameling van D;. Dat wil zeggen, een proces dat in 
Dj wordt uitgevoerd heeft meer rechten dan een proces dat in D; wordt uitge- 
voerd. Een proces dat in Do wordt uitgevoerd heeft de meeste rechten. Als er 
slechts twee ringen zijn komt deze opzet overeen met de monitor/gebruiker-mo- 
dus bij de uitvoering, waarin de monitor-modus correspondeert met Do en de 
gebruiker-modus met Di. 

Multics heeft een in segmenten verdeelde adresruimte; ieder segment is een 
bestand. Elk segment is verbonden met een van de ringen. Een segmentbeschrij- 
ving bevat onder meer een ingang die het ringnummer aangeeft en ook drie bits 
voor de besturing van lezen, schrijven en uitvoering. De relatie tussen segmenten 
en ringen is een beleidsbeslissing waarbij we in dit boek niet verder stilstaan. Met 
ieder proces is een teller met het huidige ringnummer verbonden, die de ring aan- 
geeft waarin het proces op dat moment aan zijn uitvoering bezig is. Wanneer een 
proces in uitvoering is in ring i, kan het geen toegang krijgen tot een segment dat 
verbonden is met ring j, als j < i. 
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Het kan echter wel toegang krijgen tot een segment dat verbonden is met 
ring k, als k > i. Het soort toegang is evenwel beperkt, in overeenstemming met 
de toegangsbits die bij dat segment horen. 

Domeinomschakeling heeft in Multics plaats wanneer een proces van de 
ene ring naar een andere gaat door het aanroepen van een procedure in een ande- 
re ring. Uiteraard moet deze omschakeling onder gepaste besturing plaats heb- 
ben; anders kan een proces bij zijn uitvoering wel in ring 0 terechtkomen, waar- 
door er helemaal geen beveiliging meer mogelijk is. Met het oog op een geregu- 
leerde domeinomschakeling wordt het ringveld van de segmentbeschrijver ge- 
wijzigd, zodat het onder meer bevat: 


@ Toegangspaar. Een paar gehele getallen, bl en b2, zo dat b1 < b2. 

@ Limiet. Een geheel getal b3, zo dat b3 > b2. 

@ Lijst met toegangspoorten. De punten van binnenkomst (toegangspoorten) 
waar de segmenten kunnen worden aangeroepen. 


Als een proces dat wordt uitgevoerd in ring i een procedure (segment) aanroept 
met het toegangspaar (b/,b2), dan is de aanroep toegestaan als bl < i < b2. Het 
lopende ringnummer van het proces blijft daarbij gelijk aan i. Anders gaat er een 
val naar het besturingssysteem open en wordt de situatie als volgt behandeld: 


@ Alsi < bl, is de aanroep toegestaan, omdat we een overdracht hebben naar 
een ring (domein) met minder rechten. Als er echter parameters worden door- 
gegeven die naar segmenten in een lagere ring (dat wil zeggen, segmenten die 
niet toegankelijk zijn voor de aangeroepen procedure) verwijzen, dan moeten 
deze segmenten worden gekopieerd naar een gebied waartoe de aangeroepen 
procedure toegang heeft. 

@ Als i > b2, is de aanroep alleen toegestaan als de limiet (53) kleiner dan of 
gelijk aan i is en de aanroep gericht is tot een van de aangewezen punten van 
toegang in de lijst met toegangspoorten. Deze opzet geeft de mogelijkheid dat 
processen met beperkte toegangsrechten procedures aanroepen in lagere rin- 
gen met meer toegangsrechten, maar alleen op een met zorg gereguleerde wijze. 


Het belangrijkste nadeel van de (hiërarchische) ringstructuur is dat deze ons niet 
toestaat het ’alleen-waar-nodig’ (need-to-know) principe op te leggen. In het bij- 
zonder moet, als een object toegankelijk moet zijn in domein Dj, maar niet toe- 
gankelijk in domein D;, j < i zijn. Maar dit betekent dat elk segment dat toegan- 
kelijk is in D;, ook toegankelijk is in Dj. 


11.8.3 Hydra 


Hydra is een beveiligingssysteem dat werkt met het beschikkingsrecht en dat 
aanzienlijke flexibiliteit geeft. Het systeem biedt een vaste groep mogelijke toe- 
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gangsrechten, die aan het systeem bekend zijn en daardoor geïnterpreteerd wor- 
den. Deze rechten omvatten fundamentele vormen van toegang zoals het recht 
om uit een geheugensegment te lezen, ernaar te schrijven of het uit te voeren. 
Bovendien verschaft het systeem een gebruiker (van het beveiligingssysteem) de 
middelen om extra rechten te declareren. De interpretatie van door de gebruiker 
gedefinieerde rechten vindt alleen plaats door het programma van de gebruiker, 
maar het systeem verleent toegangsbeveiliging voor het gebruik van deze rechten, 
alsook voor het gebruik van de door het systeem bepaalde rechten. De voorzie- 
ningen die door dit systeem worden geleverd zijn heel interessant en vormen een 
aanzienlijke bijdrage tot de ontwikkeling van de beveiligingstechnologie. 

Bewerkingen die op objecten worden uitgevoerd zijn met behulp van proce- 
dures gedefinieerd. De procedures die zulke bewerkingen implementeren zijn zelf 
een vorm van object en toegang daartoe vindt indirect plaats via beschikkings- 
rechten. De namen van door de gebruiker gedefinieerde procedures moeten aan 
het beveiligingssysteem worden opgegeven als deze bestemd zijn om te werken 
met objecten die door de gebruiker gedefinieerd zijn. Wanneer de definitie van 
een object aan Hydra bekend wordt gemaakt, worden de namen van door de 
gebruiker gedefinieerde bewerkingen op dat type nevenrechten. Nevenrechten 
kunnen in een beschikkingsrecht worden beschreven voor een exemplaar van het 
type. Wil nu een proces een bewerking uitvoeren op een object van een bepaald 
type, dan moet in het beschikkingsrecht dat het proces voor dat object heeft, 
onder de nevenrechten de naam voorkomen van de bewerking die wordt aange- 
roepen. Deze beperking maakt het mogelijk toegangsrechten van elkaar te onder- 
scheiden naar exemplaar en naar proces. 

Een ander interessant begrip in Hydra wordt rechtenuitbreiding genoemd 
[Cohen en Jefferson 1975]. Deze methode biedt de mogelijkheid een procedure 
als ’betrouwbaar’ aan te merken, waarop deze dan het recht tot actie heeft op 
grond van een formele parameter van een aangegeven type, uit naam van elk 
proces dat het recht bezit de procedure uit te voeren. De rechten van een betrouw- 
bare procedure zijn onafhankelijk van, en kunnen meeromvattend zijn dan, de 
rechten van het proces dat de aanroep deed. Het is daarentegen niet noodzakelijk 
zo’n procedure als universeel betrouwbaar te beschouwen (hij mag bijvoorbeeld 
niet op andere typen werken), noch is het noodzakelijk de betrouwbaarheid uit 
te strekken tot andere procedures of programmasegmenten die door een proces 
uitgevoerd zouden kunnen worden. | 

Uitbreiding is nuttig bij het aan implementatie-procedures toegang verle- 
nen tot de representatievariabelen van een abstract gegevenstype. Als bijvoor- 
beeld een proces een beschikkingsrecht heeft voor een object van een bepaald 
type A, kan tot dit beschikkingsrecht een nevenrecht behoren voor het aanroepen 
van een bewerking P op het segment dat A vertegenwoordigt, hoewel de zoge- 
naamde kernrechten, zoals lezen, schrijven of uitvoeren, daar niet in begrepen 
zijn. Zo’n beschikkingsrecht biedt een proces een middel voor indirecte toegang 
(via de bewerking P) tot de representatie van A, maar alleen voor specifieke doel- 
einden. 


11.8 Bestaande systemen 


Aan de andere kant kan, wanneer een proces de bewerking P op een object 
A aanroept, het beschikkingsrecht voor toegang tot A uitgebreid worden wanneer 
de besturing aan de rompcode van P wordt gegeven. Dit kan nodig zijn om P 
het recht te geven toegang te krijgen tot het geheugensegment dat A representeert, 
om de bewerking P op het abstracte gegevenstype te implementeren. De romp- 
code van P kan toestemming krijgen het segment van A rechtstreeks te lezen of 
ernaar te schrijven, zelfs als het aanroepende proces dit niet kan. Bij terugkeer 
van P wordt het beschikkingsrecht van A hersteld in zijn oude, niet-uitgebreide 
toestand. Dit is een typisch geval waarin de rechten in het bezit van een proces, 
wil het toegang krijgen tot een beveiligd segment, dynamisch moeten veranderen, 
afhankelijk van de taak die moet worden verricht. De dynamische aanpassing van 
rechten vindt plaats om consistentie van een door de programmeur gedefinieerde 
abstractie te garanderen. In het Hydra-systeem kan rechtenuitbreiding expliciet 
worden vermeld in de declaratie van een abstract gegevenstype. 

Een Hydra-subsysteem wordt aan de Hydra-beveiligingskern aangebouwd 
en kan daarom beveiliging van Hydra’s eigen componenten vereisen. Een subsys- 
teem staat in wisselwerking met de kern via aanroepen van een groep door de 
kern gedefinieerde elementaire functies die de toegangsrechten tot door het sub- 
systeem gedefinieerde systeemfaciliteiten bepalen. Beleidsregels voor het gebruik 
van deze systeemfaciliteiten door gebruikersprocessen kunnen door de systeem- 
ontwerper worden gedefinieerd, maar moeten worden opgelegd met gebruik- 
making van de standaardtoegangsbeveiliging die wordt geleverd door het be- 
schikkingsrechtsysteem. 

Een programmeur kan rechtstreeks van het beveiligingssysteem gebruik 
maken, nadat hij zich met de functies daarvan vertrouwd heeft gemaakt, door 
bestudering van het handboek [Newcomer et al. 1976]. Hydra heeft een grote 
bibliotheek van door het systeem gedefinieerde procedures, die door gebruikers- 
programma’s kunnen worden aangeroepen. Een gebruiker van het Hydra-sys- 
teem zal expliciete aanroepen van deze systeemprocedures in zijn programma 
opnemen, of hij zal een programmavertaler gebruiken die met Hydra is gekop- 
peld. 


11.8.4 Het Cambridge CAP-systeem 


Een heel andere benadering van op beschikkingsrecht gebaseerde beveiliging 
werd gevolgd in het ontwerp van het Cambridge CAP-systeem [Needham en Wal- 
ker 1977]. Het beschikkingsrechtsysteem ervan is ogenschijnlijk eenvoudiger en 
oppervlakkig gezien minder krachtig dan dat van Hydra. Bij nadere beschouwing 
echter blijkt dit systeem eveneens te kunnen worden gebruikt om door de gebrui- 
ker gedefinieerde objecten beveiligingszekerheid te bieden. CAP kent twee typen 
beschikkingsrechten. Het gewone type wordt een gegevensbeschikkingsrecht ge- 
noemd. Het kan gebruikt worden om toegang tot objecten te verlenen, maar de 
enige rechten die gegeven worden zijn de standaardrechten van lezen, schrijven 
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of uitvoeren van de afzonderlijke geheugensegmenten die met het object verbon- 
den zijn. Gegevensbeschikkingsrechten worden vertolkt door de microcode van 
de CAP-machine. 

Een zogenaamd programmatuur-beschikkin gsrecht wordt beveiligd, maar 
niet vertolkt, door de CAP-microcode. Het wordt vertolkt door een beveiligde 
(dat wil zeggen, een bevoorrechte) procedure, die door een toepassingsprogram- 
meur als onderdeel van een subsysteem geschreven kan zijn. Met een beveiligde 
procedure is een speciaal soort uitbreiding van rechten verbonden. Bij het uitvoe- 
ren van de rompcode van zo’n procedure, verkrijgt een proces tijdelijk de rechten 
om de inhoud van een programmatuur-beschikkingsrecht te lezen of deze zelf te 
schrijven. Dit speciale soort rechtenuitbreiding komt overeen met cen implemen- 
tatie van de elementaire beschikkingsrechtfuncties verzegel en ontzegel die wer- 
den voorgesteld door Morris [1973]. Natuurlijk is dit privilege nog steeds onder- 
worpen aan controle op het type, om te waarborgen dat alleen programmatuur- 
beschikkingsrechten voor een gespecificeerd abstract type aan een dergelijke pro- 
cedure mogen worden doorgegeven. Universeel vertrouwen wordt in geen enkele 
code gesteld, afgezien dan van de microcode van de CAP-machine. 

De interpretatie van een programmatuur-beschikkingsrecht ligt geheel bij 
het subsysteem, via de beveiligde procedures die het bevat. Deze methode biedt 
de mogelijkheid een groot aantal verschillende beleidsvormen te implementeren. 
Hoewel programmeurs hun eigen beveiligde procedures (die elk wel incorrect 
kunnen zijn) kunnen definiéren, kan ten aanzien van de veiligheidszekerheid van 
het systeem als geheel niet worden geschipperd. Het basisbeveiligingssysteem zal 
niet toestaan dat een niet-gecontroleerde, door de gebruiker gedefinieerde, bevei- 
ligde procedure toegang krijgt tot geheugensegmenten (of beschikkingsrechten) 
die niet behoren tot de beveiligingsomgeving waarin de procedure opereert. Het 
ergste gevolg van een niet met zekerheid beveiligde procedure is dat het misgaat 
met de beveiliging van het subsysteem waarvoor het verantwoordelijkheid draagt. 

De ontwerpers van het CAP-systeem hebben opgemerkt dat het gebruik 
van programmatuur-beschikkingsrechten het hen mogelijk heeft gemaakt daar- 
van aanzienlijk profijt te trekken bij het formuleren en implementeren van een 
beveiligingsbeleid dat strookt met de vereisten van abstracte systeemfaciliteiten. 
Ontwerpers van deelsystemen echter, die van deze voorziening gebruik willen 
maken, kunnen niet volstaan met het simpel bestuderen van een handboek, zoals 
dat het geval is bij Hydra. In plaats daarvan moeten zij de principes en technieken 
van beveiliging leren, aangezien het systeem niet beschikt over een bibliotheek 
met procedures die men maar hoeft te gebruiken. 


11.9 Op taal gebaseerde beveiliging 


De mate van beveiliging die bestaande systemen leveren is gewoonlijk tot stand 
gebracht met behulp van een besturingssysteemkern, die als een veiligheidsagent 
iedere poging om tot een beveiligd systeemelement toegang te krijgen op zijn 
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geldigheid moet controleren. Aangezien uitgebreide toegangscontrole potentieel 
een bron van aanzienlijke overhead is, moet er óf ondersteuning zijn door de 
apparatuur om de kosten van iedere controle te drukken, óf men moet accepteren 
dat de systeemontwerper wel eens de neiging kan hebben het met de beveiligings- 
doelstellingen op een akkoordje te gooien. Het is moeilijk aan al deze doelstellin- 
gen te voldoen als de flexibiliteit om diverse vormen van beveiligingsbeleid te. 
implementeren aan banden wordt gelegd door de geboden ondersteuningsme- 
chanismen, of als beveiligingsomgevingen ruimer dan nodig worden gemaakt om 
grotere bedrijfsefficiéntie te waarborgen. 

Naarmate besturingssystemen complexer werden, en speciaal naarmate 
men trachtte koppelingen naar de gebruiker op hoger niveau te leveren, zijn de 
beveiligingsdoelstellingen steeds meer verfijnd. Daarbij hebben de ontwerpers 
van beveiligingssystemen intensief gebruik gemaakt van ideeën die uit program- 
meertalen afkomstig zijn, met name van het begrip abstracte gegevenstypen 
(hoofdstuk 10). Beveiligingssystemen richten zich nu niet alleen op de identiteit 
van een systeemelement waartoe wordt gepoogd toegang te verkrij gen, maar ook 
op de functionele aard van die toegang. In de nieuwste beveiligingssystemen gaat 
de betrokkenheid met de functie die moet worden aangeroepen verder dan een 
groep door het systeem gedefinieerde functies, zoals standaardmethoden voor 
bestandstoegang, en houdt deze tevens rekening met door de gebruiker gedefi- 
nieerde functies. 

Beleidsvormen voor het gebruik van systeemfaciliteiten kunnen ook ver- 
schillen, afhankelijk van de toepassing, en ze kunnen aan tijdsafhankelijke wij- 
zigingen onderworpen zijn. Om deze redenen kan beveiliging niet langer als uit- 
sluitend een zaak van de systeemontwerper beschouwd worden. Beveiliging moet 
eveneens beschikbaar zijn als een stuk gereedschap dat aan de ontwerper van 
toepassingen ten dienste staat, zodat systeemfaciliteiten van een toepassingen- 
subsysteem beveiligd kunnen worden tegen knoeierijen of de invloed van een 
fout. 

Op dit punt verschijnen programmeertalen ten tonele. Het specificeren van 
de gewenste toegangsbeschikking tot een gemeenschappelijk gebruikt systeemele- 
ment is een declaratie-opdracht voor de systeemfaciliteit. Dit soort opdracht kan 
in een taal geïntegreerd worden door uitbreiding van de voorziening bepaalde 
gegevenstypen te kunnen definiëren. Wanneer beveiliging in combinatie met ge- 
gevenstypen wordt gedefinieerd, kan de ontwerper van elk subsysteem de bevei- 
ligingseisen specificeren en ook het gebruik van andere systeemfaciliteiten in het 
systeem. Zo'n specificatie moet direct bij het samenstellen van het programma 
worden gegeven, en wel in de taal waarin het programma zelf wordt geschreven. 
Deze aanpak heeft diverse duidelijke voordelen: 


l. Beveilingingseisen worden gewoon gedeclareerd, in plaats van geprogram- 
meerd als een reeks procedure-aanroepen binnen een besturingssysteem. 

2. Beveiligingseisen kunnen onafhankelijk van de voorzieningen van een bepaald 
besturingssysteem worden geformuleerd. 
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3. De middelen om beveiliging op te leggen hoeven niet door de ontwerper van 
een subsysteem te worden geleverd. 

4. Een notatie in de vorm van een declaratie is normaal, omdat toegangsprivile- 
ges nauw verbonden zijn met het begrip abstract gegevenstype. 


Hoe kan een beveiligingsmechanisme door het vertaalprogramma worden 
geïmplementeerd? De traditionele verantwoordelijkheid van een taalimplementa- 
tie is dat opdrachten in de vorm van algoritmen geschreven in de programmeer- 
taal vertaald kunnen worden in een stuk machinecode dat het algoritme op een 
doelmachine zal uitvoeren. Als ook beveiligingsdomeinen kunnen worden gespe- 
cificeerd, moet een implementatie waarborgen dat geen enkele vertaling een pro- 
ces in staat kan stellen toegang te verkrijgen tot systeemfaciliteiten die buiten het 
van te voren bepaalde domein van het proces vallen, of de opdrachten van het 
algoritme van de programmeur nu correct zijn of niet. Er is een aanzienlijk ver- 
schil tussen het leveren van een implementatie van programma-opdrachten en 
het maken van een implementatie van beveiligingsspecificaties. Opdrachten zijn 
procedureel en kunnen rechtstreeks één voor één vertaald worden in een reeks 
instructies in machinecode. Beveiligingsspecificates zijn echter niet procedureel. 
Deze moeten geïnterpreteerd worden door een instrument dat door de implemen- 
tatie moet worden geleverd. 

Het grootste obstakel voor het opnemen van beveiligingsspecificaties bin- 
nen een programmeertaal is misschien wel het ontbreken van standaardme- 
chanismen, of zelfs iets wat daarop lijkt, voor het opleggen van beveiliging voor 
die verscheidenheid aan computersystemen. Hoewel de meeste computers die in 
de handel zijn voldoende ondersteuning door de apparatuur en het besturingssys- 
teem leveren om programma’s die in een opdrachtgerichte taal, zoals FOR- 
TRAN, COBOL, ALGOL, PL/I of Pascal geschreven zijn, direct te kunnen ver- 
talen, zijn er betrekkelijk weinig systemen die ondersteuning bieden voor de be- 
veiliging van afzonderlijke geheugensegmenten binnen de werkruimte van een 
gebruiker. | 

Er zijn allerlei technieken om beveiliging op te leggen die door de imple- 
mentatie van een programmeertaal geleverd kunnen worden, maar voor het geven 
van veiligheidszekerheid is elk van deze technieken afhankelijk van een zekere 
mate van ondersteuning van de machine in kwestie en zijn besturingssysteem. 
Stel bijvoorbeeld dat een taal zou worden gebruikt om machinecode te genereren 
die op het Cambridge CAP-systeem moet draaien. Op dit systeem vindt iedere 
geheugenverwijzing binnen de apparatuur indirect plaats via een beschikkings- 
recht. Daardoor kan geen proces ooit toegang krijgen tot een systeemfaciliteit 
buiten zijn beveiligingsomgeving. Een programma kan evenwel willekeurige be- 
perkingen opleggen aan de manier waarop een systeemfaciliteit tijdens de uitvoe- 
ring van een bepaald stuk programmacode door elk proces gebruikt mag worden. 
Zulke beperkingen kunnen heel gemakkelijk worden geïmplementeerd door de 
programmatuur-beschikkingsrechten van CAP te gebruiken. Een taalimplemen- 
tatie zou beveiligde standaardprocedures voor het interpreteren van program- 
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matuur-beschikkingsrechten kunnen leveren, die het beveiligingsbeleid dat in een 
taal gespecificeerd kan worden zouden realiseren. Deze methode legt het speci- 
ficeren van een beleid in de handen van de programmeurs, waarbij ze zich niet 
hoeven te bekommeren om hoe het opleggen van dit beleid moet worden geïmple- 
menteerd. 

Zelfs al heeft een systeem niet zo’n krachtige beveiligingskern als die van 
Hydra, CAP of Multics, dan zijn er toch in een programmeertaal gegeven me- 
chanismen beschikbaar voor de implementatie van beveiligingsspecificaties. Het 
hoofdonderscheid is dat de veiligheidszekerheid van deze beveiliging niet zo groot 
zal zijn als die welke ondersteund wordt door een beveiligingskern, omdat het 
mechanisme moet vertrouwen op nog andere aannamen over de bedrijfstoestand 
van het systeem. Een compileerprogramma kan verwijzingen waarvoor zeker geen 
beveiligingsschending kan optreden scheiden van die waarvoor een schending 
mogelijk zou zijn en ze verschillend behandelen. De veiligheidszekerheid die door 
deze vorm van beveiliging wordt geleverd staat of valt met de aanname dat de 
code die door het compileerprogramma wordt gegenereerd niet zal worden ge- 
wijzigd voor of tijdens de uitvoering daarvan. 

Wat heeft dan het opleggen van beveiliging uitsluitend door een kern vóór 
op het opleggen van beveiliging grotendeels door een compileerprogramma? 


@ Veiligheidszekerheid. Het opleggen van beveiliging door een kern geeft een 
grotere mate van veiligheidszekerheid van het beveiligingssysteem zelf dan het 
genereren van code die de beveiliging moet controleren door een compileer- 
programma. In de laatste opzet staat of valt de veiligheidszekerheid met de 
correctheid van het vertaalprogramma, met het mechanisme voor geheugen- 
beheer dat de segmenten beveiligt waarin de vertaalde code wordt uitgevoerd 
en tenslotte met de veiligheidszekerheid van de bestanden van waaruit een 
programma geladen wordt. Enkele van deze overwegingen zijn ook wel van 
toepassing op de beveiligingskern die door de programmatuur wordt onder- 
steund, maar in mindere mate, omdat de kern in vaste geheugensegmenten 
kan verblijven en mogelijk alleen geladen wordt vanuit een voor dat doel ge- 
reserveerd bestand. Met een beschikkingsrechtsysteem met etiketten (tagged 
capability system), waarin de gehele adresberekening óf door de apparatuur 
of door een vast programma in de microcode wordt gedaan, is zelfs nog grotere 
veiligheidszekerheid mogelijk. Beveiliging die door de apparatuur ondersteund 
wordt is ook betrekkelijk immuun voor beveiligingsschendingen die zouden 
kunnen optreden als gevolg van een storing in de apparatuur of in de systeem- 
programmatuur. 

@ Flexibiliteit. Bij de implementatie van een door de gebruiker gedefinieerd be- 
leid kent de flexibiliteit van een beveiligingskern toch zijn grenzen, al biedt 
deze het systeem wellicht de juiste mogelijkheden om zijn eigen beleid op te 
leggen. Met een programmeertaal kan een beveiligingsbeleid worden gede- 
clareerd en kan dit beleid, al naar dat nodig is, worden opgelegd door een 
implementatie. Als een taal niet voldoende flexibiliteit biedt, kan de taal wor- 
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den uitgebreid of vervangen; hierdoor wordt de dienstverlening van het sys- 
teem minder verstoord dan het geval zou zijn indien de kern in het besturings- 
systeem gewijzigd zou moeten worden. 

@ Efficiëntie. De grootste efficiëntie wordt verkregen wanneer het opleggen van 
de beveiliging direct wordt ondersteund door de apparatuur (of de microcode). 
Voor zover ondersteuning door de programmatuur is vereist, heeft het opleg- 
gen van de beveiliging die op de taal is gebaseerd het voordeel dat statische 
handhaving van de toegangsbeveiliging niet-gekoppeld kan worden gecontro- 
leerd tijdens het vertalen. Ook kan de overhead van het aanroepen van de kern 
dikwijls vermeden worden, omdat het mechanisme voor het handhaven van de 
beveiliging door een intelligent compileerprogramma wel pasklaar gemaakt 
kan worden voor specifieke behoeften. 


In het kort, de beveiligingsspecificatie in een programmeertaal maakt het 
mogelijk het beleid voor de toewijzing en het gebruik van systeemfaciliteiten op 
hoog niveau te beschrijven. Een taalimplementatie kan programmatuur leveren 
voor het handhaven van de beveiliging wanneer automatische, door de appara- 
tuur ondersteunde controle niet beschikbaar is. Bovendien kan deze de interpre- 
tatie verzorgen van beveiligingsspecificaties om aanroepen te genereren van het 
beveiligingssysteem, dat wordt geleverd door de apparatuur en het besturingssys- 
teem. 

Morris [1973] heeft een soort ’programmatuur-beschikkingsrecht’ voorge- 
steld dat gebruikt zou kunnen worden als een verwerkingsobject. Aan dit begrip 
ligt de gedachte ten grondslag dat bepaalde programmacomponenten het voor- 
recht zouden kunnen hebben deze programmatuur-beschikkingsrechten te cre- 
éren of deze te inspecteren. Een programma dat beschikkingsrechten creëert zou 
dan in staat zijn een fundamentele bewerking uit te voeren die een gegevensstruc- 
tuur verzegelt, waardoor de inhoud ervan ontoegankelijk wordt gemaakt voor 
alle programmacomponenten die niet in het bezit zijn van de verzegel- en ontze- 
gelvoorrechten. Ze zouden de gegevensstructuur mogen kopiëren, of het adres 
ervan doorgeven aan andere programmacomponenten, zonder evenwel toegang 
te krijgen tot de inhoud. De beweegreden voor het introduceren van zulke pro- 
grammatuur-beschikkingsrechten is dat men een beveiligingsmechanisme in de 
programmeertaal wil aanbrengen. Het enige probleem bij het denkbeeld zoals dit 
-is voorgesteld is, dat het gebruik van de verzegel- en ontzegel-bewerkingen een 
procedurele aanpak vereist voor het specificeren van beveiliging. Een niet-proce- 
durele notatie of declaratieve notatie schijnt de beste manier te zijn om bevei- 
liging aan de toepassingsprogrammeur beschikbaar te stellen. 

Nodig is een veilig, dynamisch toegangsbesturingsmechanisme voor het ver- 
delen van beschikkingsrechten voor systeemfaciliteiten onder de gebruikerspro- 
cessen. Wil dit toegangsbesturingsmechanisme bijdragen tot de algehele betrouw- 
baarheid van een systeem, dan moet het veilig gebruikt kunnen worden. Wil het 
in de praktijk nuttig zijn, dan moet het ook redelijk efficiënt zijn. Deze eis heeft 
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geleid tot het ontwikkelen van een aantal nieuwe taalconstructies die een me- 
chanisme leveren voor het veilig en efficiënt verdelen van beschikkingsrechten 
onder de gebruikersprocessen ([Silberschatz et al. 1977), [Kieburtz en Silberschatz 
1978] en [McGraw en Andrews 1979]). Deze mechanismen bieden de garantie 
dat een gebruikersproces de beheerde systeemfaciliteit alleen zal gebruiken als 
daarvoor aan het proces een beschikkingsrecht werd verleend. Ze geven echter 
niet de garantie dat het gebruikersproces de gemeenschappelijk gebruikte sys- 
teemfaciliteiten ook op de juiste wijze zal gebruiken. Er is een mechanisme nodig 
dat de programmeur de mogelijkheid biedt om bepaalde beperkingen te decla- 
reren: 


@ Beperkingen aangaande de specifieke bewerkingen die een bepaald proces mag 
doen op een toegewezen systeemfaciliteit (een leesproces bijvoorbeeld mag al- 
leen het bestand lezen, terwijl een schrijfproces zowel moet kunnen lezen als 
schrijven). Het moet niet nodig zijn aan elk gebruikersproces dezelfde groep 
rechten te verlenen en het moet voor een proces onmogelijk zijn zijn groep 
toegangsrechten uit te breiden, behalve wanneer het door het toegangsbe- 
sturingsmechanisme daartoe geautoriseerd is. 

@ Beperkingen aangaande de volgorde waarin een bepaald proces de verschillen- 
de bewerkingen van een systeemfaciliteit kan aanroepen (een bestand bijvoor- 
beeld moet worden geopend voordat het gelezen kan worden). Het moet moge- 
lijk zijn aan twee processen verschillende beperkingen op te leggen voor de 
volgorde waarin zij de bewerkingen van de toegewezen systeemfaciliteit kun- 
nen aanroepen. 


Een notatie voor het specificeren van toegangsrechtexpressies, waarmee 
men zulke beperkingen kan declareren, werd niet zo lang geleden voorgesteld 
door Kieburtz en Silberschatz [1983]. Toegangsrechtexpressies geven de garantie 
dat een proces alleen met name genoemde bewerkingen kan gebruiken en dat het 
proces de bewerkingen alleen aanroept in een volgorde zoals die is voorzien door 
de ontwerper van de systeemfaciliteit. De notatie is gebaseerd op gewone expres- 
sies, die een vertrouwd referentiekader bieden en voldoende uitdrukkingskracht 
schijnen te hebben om de meeste volgordebeperkingen die van praktisch belang 
zijn te beschrijven. 

Het inbouwen van beveiligingsbegrippen in programmeertalen, als een 
praktisch stuk gereedschap bij het ontwerpen van systemen, staat op dit moment 
nog maar in de kinderschoenen. Het ziet ernaar uit dat beveiliging steeds meer 
de aandacht zal gaan vragen van de ontwerpers van nieuwe systemen met gedis- 
tribueerde verwerking en steeds toenemende eisen op het gebied van de veilig- 
heidszekerheid van gegevens. Naarmate dit werkelijkheid gaat worden, zal het 
belang van geschikte taalnotaties waarin beveiligingseisen kunnen worden uitge- 
drukt in steeds wijdere kring worden erkend. 
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11.10 Beveiligingsproblemen 


De mechanismen die we tot nu toe in grote lijnen hebben aangegeven, leveren 
een besturingssysteem met krachtige hulpmiddelen voor het opbouwen van elk 
willekeurig beveiligingsbeleid. Het probleem van het beveiligen van informatie 
in een besturingssysteem heeft in de laatste jaren sterk de aandacht gekregen. 
Men heeft diverse belangrijke problemen gedefinieerd, waarvoor niet altijd een 
gemakkelijke (of zelfs mogelijke) oplossing voorhanden is. 


@ Wijziging. Wanneer een gebruiker een object als argument voor een procedure 
doorgeeft, kan het noodzakelijk zijn te waarborgen dat de procedure het object 
niet kan wijzigen. Deze beperking kan gemakkelijk worden geïmplementeerd 
door een toegangsrecht door te geven waarin niet het recht tot wijziging 
(schrijfrecht) voorkomt. Als echter uitbreiding kan plaatsvinden (zoals in Hy- 
dra), kan het recht om te mogen wijzigen hersteld worden. Op deze wijze kan 
de eis van gebruikersbeveiliging omzeild worden. 

In het algemeen moet een gebruiker er natuurlijk op kunnen vertrouwen 
dat een procedure werkelijk zijn taak correct uitvoert. Deze veronderstelling 
is evenwel niet juist, wegens het vóórkomen van storingen in de apparatuur en 
in de programmatuur. Hydra lost dit probleem op door uitbreidingen aan ban- 
den te leggen. 

© Beperkte overdracht van toegangsrechten. Wanneer de eigenaar van een object 
sommige gebruikers toegang wenst te geven tot dat object, dan wil de eigenaar 
er wellicht zeker van zijn dat die gebruikers niet op hun beurt de toegangsrech- 
ten overdragen aan andere, niet-geautoriseerde gebruikers. Dit kan worden 
bereikt door de kopieer- en eigenaarsrechten alleen met de eigenaar van het 
object te verbinden. U merkt wel dat deze beperking het probleem niet geheel 
oplost, daar gebruiker A (die toestemming heeft) gebruiker B (die geen toe- 
stemming heeft) kan toestaan als gebruiker A in te loggen en tot het object 
toegang te krijgen. 

@ Herroeping. Een gebruiker of een systeem kan een eerder verleend toegangs- 
recht tot een object om verschillende redenen willen herroepen. We hebben in 
paragraaf 11.7 al besproken hoe herroeping in zijn werk gaat. 

@ Het paard van Troje. Veel systemen hebben mechanismen om het mogelijk 
te maken dat programma’s die door gebruikers geschreven zijn door andere 
gebruikers worden gebruikt. Als deze programma’s worden uitgevoerd in een 
domein dat de toegangsrechten aan de uitvoerende gebruiker verleent, zou 
deze van die rechten wel eens misbruik kunnen maken. Binnen een tekstop- 
maakprogramma bijvoorbeeld kan code voorkomen om in het op te maken 
bestand naar bepaalde sleutelwoorden te zoeken. Als er een wordt gevonden 
kan het gehele bestand naar een speciaal gebied worden gekopieerd dat toe- 
gankelijk is voor de persoon die het tekstopmaakprogramma gemaakt heeft. 
Een codesegment dat zijn omgeving misbruikt wordt een paard van Troje ge- 
noemd. 
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@ Wederzijdse verdenking. Neem het geval waarin een programma wordt gele- 
verd dat als een dienstverleningsfunctie door een aantal verschillende gebrui- 
kers kan worden aangeroepen. Dit functieprogramma kan een subroutine zijn 
voor het sorteren van een reeks, een compileerprogramma, een programma 
voor controle van de administratie, of een spelletje. Wanneer gebruikers dit 
functieprogramma aanroepen, nemen zij het risico dat het programma ver- 
keerd kan functioneren en hun gegevens vernielen of een of ander toegangs- 
recht tot hun bestanden kan achterhouden dat dan later (zonder autorisatie) 
kan worden gebruikt. Evenzo kan het functieprogramma wel een aantal privé- 
bestanden hebben (voor administratieve doeleinden bijvoorbeeld) waartoe het 
aanroepende gebruikersprogramma niet rechtstreeks toegang mag hebben. Dit 
probleem noemt men het probleem van het wederzijds verdachte subsysteem. Het 
mechanisme voor het aanroepen van procedures in Hydra werd als een directe 
oplossing voor dit probleem ontworpen. 

@ Opsluiting. De kopieer- en eigendomsrechten geven ons een mechanisme om 
de overdracht van toegangsrechten te beperken. Zij geven ons echter niet de 
geschikte instrumenten om de verspreiding van informatie (dat wil zeggen, het 
openbaar maken van informatie) te voorkomen. Het probleem, dat we moeten 
garanderen dat geen informatie die aanvankelijk in een object wordt bewaard 
buiten zijn uitvoeringsomgeving wordt verspreid, wordt het opsluitingspro- 
bleem genoemd [Lampson 1973]. Dit probleem kan in het algemeen niet wor- 
den opgelost. 
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Beveiliging is, zoals we hebben besproken, strikt genomen een intern probleem: 
hoe geven we gereguleerde toegang tot programma’s en gegevens die opgeslagen 
zijn in een computersysteem? Veiligheidszekerheid vereist aan de andere kant 
niet alleen een doeltreffend beveiligingssysteem, maar ook het rekening houden 
met de externe omgeving waarin het systeem werkt. Interne beveiliging heeft niets 
om het lijf als het bedieningspaneel van de operateur vrij toegankelijk is voor 
niet-geautoriseerd personeel, of als bestanden (dat wil zeggen, magneetbanden 
en schijven) gewoon van het computersysteem kunnen worden weggehaald en 
meegenomen naar een systeem dat geen beveiliging heeft. Dit soort veiligheids- 
problemen zijn in wezen problemen van de directie, niet die van het besturings- 
systeem. 

Het hoofdprobleem op het gebied van de veiligheidszekerheid is het pro- 
bleem van de authenticiteit. Het beveiligingssysteem is afhankelijk van het vermo- 
gen de programma’s en processen die worden uitgevoerd correct te identificeren. 
‘Dit hangt er weer van af of we in staat zijn elke gebruiker van het systeem correct 
te identificeren. Gebruikers identificeren zich gewoonlijk. Hoe stellen we vast of 
de identiteit van een gebruiker echt is? 

De meest gebruikte aanpak voor het controleren van de identiteit van een 
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gebruiker is het gebruik van wachtwoorden voor gebruikers. Wanneer gebruikers 
zich bekendmaken wordt hen een wachtwoord gevraagd. Als het door de gebrui- 
ker gegeven wachtwoord overeenkomt met het wachtwoord dat in het systeem is 
opgeslagen, wordt aangenomen dat de gebruiker zich voldoende gelegitimeerd 
heeft. | 

Wachtwoorden worden vaak gebruikt om objecten in het computersysteem 
te beveiligen als volledigere beveiligingsschema’s ontbreken. Wachtwoorden kun- 
nen worden beschouwd als een speciaal geval van sleutels óf beschikkingsrechten. 
Met iedere systeemfaciliteit (zoals een bestand) is een wachtwoord verbonden. 
Telkens wanneer er een verzoek om de systeemfaciliteit wordt gedaan moet het 
wachtwoord worden gegeven. Als het wachtwoord correct is wordt de toegang 
verleend. Verschillende wachtwoorden kunnen met verschillende toegangsrech- 
ten worden verbonden. Om een voorbeeld te geven, voor het lezen van, toevoegen 
aan en bijwerken van een bestand kunnen verschillende wachtwoorden worden 
gebruikt. | 

Er zijn wel problemen met wachtwoorden, maar deze zijn uiterst triviaal, 
omdat wachtwoorden gemakkelijk te begrijpen en te gebruiken zijn. De proble- 
men houden verband met de moeilijkheid een wachtwoord geheim te houden. 
Wachtwoorden missen hun doel als ze geraden worden of als iemand ze per on- 
geluk ziet. Dat iemand een wachtwoord ziet is vooral een probleem als het wacht- 
woord ergens wordt opgeschreven waar het kan worden gelezen of zoek raakt. 
Korte wachtwoorden bieden niet genoeg keus om te voorkomen dat ze door her- 
haald proberen geraden kunnen worden. Een wachtwoord van bijvoorbeeld vier 
cijfers geeft slechts 10.000 mogelijke variaties. Gemiddeld hoeft men slechts 5.000 
maal te proberen voor het juiste wachtwoord geraden is. Als men een programma 
zou kunnen schrijven dat iedere milliseconde een wachtwoord probeert, zou het 
slechts 5 seconden nodig hebben om achter een wachtwoord te komen. Met lan- 
gere wachtwoorden is de kans dat men alleen door te proberen een wachtwoord 
vindt kleiner. 

Wachtwoorden kunnen ofwel door het systeem gegenereerd of door de ge- 
bruiker gekozen zijn. Door het systeem gegenereerde wachtwoorden zijn soms 
moeilijk te onthouden en worden daarom in de regel opgeschreven. Door de ge- 
bruiker gekozen wachtwoorden zijn dikwijls gemakkelijk te raden (de naam of 
initialen van de gebruiker bijvoorbeeld). Sommige bedrijven hebben systeem- 
beheerders die zo nu en dan de wachtwoorden van de programmeurs controleren 
en de programmeurs laten weten dat hun wachtwoord te kort of te gemakkelijk 
te raden is. 

De eenvoudige methode van wachtwoorden laat diverse varianten toe. Het 
wachtwoord kan bijvoorbeeld dikwijls veranderd worden. In het extreme geval 
wordt aan het einde van iedere sessie het wachtwoord gewijzigd. Er wordt aan 
het eind van iedere sessie een nieuw wachtwoord gekozen (hetzij door het systeem 
hetzij door de gebruiker); dat wachtwoord moet dan gebruikt worden voor de 
volgende sessie. Let erop dat, zelfs als een wachtwoord wordt misbruikt, het 
slechts eenmaal gebruikt kan worden en dat het gebruik ervan de rechtmatige 
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gebruiker verhindert het te gebruiken. Dit heeft tot gevolg dat de rechtmatige 
gebruiker de beveiligingsschending bij de volgende sessie ontdekt, omdat hij een 
wachtwoord gebruikt dat nu ongeldig is. Er kunnen dan stappen worden geno- 
men om de situatie te corrigeren. 

Een andere aanpak is dat men een groep gekoppelde wachtwoorden heeft. 
Bij het begin van een sessie kiest het systeem er willekeurig een uit, waarna de 
gebruiker het andere deel moet geven. Deze methode kan gegeneraliseerd worden 
door als wachtwoord een algoritme te gebruiken. Het algoritme zou bijvoorbeeld 
een functie van een geheel getal kunnen zijn. Het systeem kiest een willekeurig 
geheel getal en presenteert het aan de gebruiker. De gebruiker past de functie toe 
en antwoordt met de uitkomst van de functie. Ook het systeem past de functie 
toe. Als de twee uitkomsten overeenstemmen wordt de toegang verleend. 

Eén probleem met al deze benaderingen is de moeilijkheid dat het wacht- 
woord (of lijst van wachtwoordenparen of algoritmen) geheim gehouden moet 
worden. Het Unix-systeem gebruikt een variant van het algoritmische wacht- 
woord en voorkomt hierdoor dat de lijst met wachtwoordenparen onthouden 
moet worden [Morris en Thompson 1979]. Elke gebruiker heeft een wachtwoord. 
Het systeem bevat een functie die moeilijk (hopelijk onmogelijk) te ontdekken 
valt, maar eenvoudig uit te rekenen is. Dat wil zeggen, bij een gegeven waarde 
x is het heel gemakkelijk de functiewaarde flx) te berekenen. Bij een gegeven 
functiewaarde flx) is het echter onmogelijk x te berekenen. Deze functie wordt 
gebruikt om alle wachtwoorden in een code om te zetten. Alleen de gecodeerde 
wachtwoorden worden opgeslagen. Wanneer een gebruiker een wachtwoord aan- 
biedt wordt het gecodeerd en vergeleken met het opgeslagen gecodeerde wacht- 
woord. Zelfs als iemand het gecodeerde wachtwoord ziet kan hij het niet decode- 
ren om het wachtwoord te bepalen. Op die manier hoeft het wachtwoordbestand 
niet geheim gehouden te worden. 

Men kan van twee beheerstechnieken gebruik maken om de veiligheids- 
zekerheid van een systeem te verbeteren. De ene techniek heet bedreigingscontrole 
(Engels: threat monitoring). Het systeem kan proberen een veiligheidsschending 
te ontdekken door het uitvoeren van controles op verdachte activiteitspatronen. 
Een bekend voorbeeld van deze methode is een systeem met tijddeling dat het 
aantal malen telt dat een onjuist wachtwoord wordt gegeven wanneer een gebrui- 
ker probeert in te loggen. Meer dan een paar incorrecte pogingen kunnen een 
teken zijn dat er een poging wordt ondernomen om een wachtwoord te raden. 
Een andere bekende techniek is een controlelogboek (Engels: audit log). Een con- 
trolelogboek legt eenvoudig de tijd, de gebruiker en het soort van alle toegangen 
tot een object vast. Nadat de beveiliging geschonden is, kan het controlelogboek 
worden gebruikt om vast te stellen hoe en wanneer het probleem optrad en mis- 
schien ook de hoeveelheid schade die werd aangericht. Deze informatie kan nut- 
tig zijn, zowel voor het herstellen van de schending als misschien voor het ontwik- 
kelen van betere veiligheidsmaatregelen om toekomstige problemen te voorko- 
men. 
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11.12 Samenvatting 


Computersystemen bevatten vele objecten. Deze objecten moeten tegen misbruik 
worden beveiligd. Objecten kunnen apparatuur zijn (zoals het geheugen, CVE- 
tijd, of randapparatuur), of programmatuur (zoals bestanden, programma’s en 
abstracte gegevenstypen). Een toegangsrecht is de toestemming om een bewer- 
king op een object uit te voeren. Een domein is een groep toegangsrechten. 
Processen worden uitgevoerd in domeinen en kunnen alle toegangsrechten in het 
domein gebruiken om tot objecten toegang te krijgen en deze te bewerken. 

De toegangsmatrix is een algemeen beveiligingsmodel. De toegangsmatrix 
biedt een mechanisme voor beveiliging zonder een bepaald beveiligingsbeleid aan 
het systeem of zijn gebruikers op te leggen. De scheiding van beleid en mechanis- 
me is een belangrijke eigenschap van een ontwerp. 

De toegangsmatrix is dun bevolkt en wordt gewoonlijk geïmplementeerd 
als toegangslijsten die met elk object verbonden zijn óf als lijsten met beschik- 
kingsrechten die met elk domein verbonden zijn. In het toegangsmatrixmodel 
kan ook dynamische beveiliging worden ondergebracht door domeinen en de 
toegangsmatrix zelf als objecten te beschouwen. 

Reële systemen zijn veel beperkter en geven gewoonlijk alleen beveiliging 
voor bestanden. Unix is een goed voorbeeld, omdat het voor ieder bestand lees-, 
schrijf- en uitvoeringsbeveiliging afzonderlijk biedt voor de eigenaar, de groep ge- 
bruikers en het grote publiek. Multics maakt behalve van bestandstoegang gebruik 
van een ringstructuur. Hydra en het Cambridge CAP-systeem zijn systemen die 
werken met beschikkingsrechten die beveiliging uitstrekken tot door de gebruiker 
gedefinieerde programmatuur-objecten. 

Beveiliging is een intern probleem. Veiligheidszekerheid moet betrekking 
hebben op zowel het computersysteem als de omgeving (mensen, gebouwen, be- 
drijven, waardevolle objecten en bedreigingen), waarbinnen het systeem gebruikt 
wordt. Men maakt doorgaans gebruik van wachtwoorden om het probleem van de 
authenticiteit op te lossen. 


Opgaven 


11.1 Wat zijn de belangrijkste verschillen tussen beschikkingsrechtlijsten en 
toegangslijsten? 


11.2 Een MCP-bestand op het Burroughs B7000/B6000-systeem kan een 
etiket opgeplakt krijgen: ’gevoelige gegevens’. Wanneer zulk een bestand 
wordt opgeheven, wordt zijn geheugengebied overschreven met een aan- 
tal willekeurige bits. Waarvoor zou een dergelijke methode nuttig zijn? 


11.3 In een ring-beveiligingssysteem, waarin niveau 0 de meeste toegangs- 
rechten tot objecten heeft en niveau n (groter dan nul) minder toegangs- 
rechten heeft, worden de toegangsrechten van een programma op een 


Opgaven 


11.4 


11.5 


11.6 


11.8 


11.9 


11.10 


11.11 


bepaald niveau in de ringstructuur beschouwd als een groep beschik- 
kingsrechten. Wat is het verband tussen de beschikkingsrechten van een 


domein voor een object op niveau j en een domein op niveau i, als j > 
i? 


Beschouw een systeem waarin ’computerspelletjes’ kunnen worden ge- 
speeld door studenten alleen tussen 10 uur ’s morgens en 6 uur ’s mid- 
dags, door het wetenschappelijk personeel tussen 5 uur ’s middags en 8 
uur ’s avonds en door personeel van het computercentrum op elk mo- 
ment. Bedenk een manier om dit beleid efficiënt te implementeren. 


Het RC 4000 systeem (onder andere) heeft een boom van alle processen 
gedefinieerd (een procesboom geheten), zo dat alle afstammelingen van 
een proces alleen van hun voorouders systeemfaciliteiten (objecten) en 
toegangsrechten krijgen. Op deze manier kan een afstammeling nooit de 
mogelijkheid hebben iets te doen wat zijn voorouders niet kunnen doen. 
De wortel van de boom is het besturingssysteem, dat in staat is alles 
te doen. Stel dat de groep toegangsrechten werd voorgesteld door een 
toegangsmatrix A. A(x,y) definieert de toegangsrechten van proces x 
voor object y. Als x een afstammeling is van z, wat is dan het verband 
tussen A(x,y) en A(z,y) voor een willekeurig object y? 


Een wachtwoord kan op verschillende manieren aan andere gebruikers 
bekend worden. Is er een eenvoudige methode om te ontdekken dat 
zoiets heeft plaatsgevonden? 


De lijst met alle wachtwoorden wordt binnen het besturingssysteem be- 
waard. Als een gebruiker het klaar speelt deze lijst te lezen, is er niet 
langer sprake van wachtwoordbeveiliging. Bedenk een methode om dit 
probleem te vermijden. (Aanwijzing: gebruik verschillende interne en 
externe representaties.) 


Welke voorzieningen in de apparatuur zijn er nodig om toegangsrechten 
efficiënt te behandelen? Kunnen deze voorzieningen ook worden ge- 
bruikt voor geheugenbeveiliging? 


Beschouw een omgeving waarin we met ieder proces en ieder object in 
het systeem een nummer verbinden. Stel dat we een proces met nummer 
n alleen toestaan toegang te verkrijgen tot een object met nummer m, als 
n > m. Wat voor soort beveiligingsstructuur hebben we dan? 


Welke beveiligingsproblemen kunnen zich voordoen als een gemeen- 
schappelijk gebruikte stapel voor het doorgeven van parameters wordt 
gebruikt? 


Stel dat een proces het recht krijgt slechts n maal tot een object toegang 
te krijgen. Bedenk een manier om dit beleid te implementeren. 
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11.12 Als alle toegangsrechten tot een object worden vernietigd, kan niemand 
meer tot het object toegang krijgen. Dan moet het object ook worden 
vernietigd en moet de ruimte die het bezet houdt aan het systeem worden 
teruggegeven. Bedenk een efficiënte implementatie van deze opzet. 


11.13 Wat is het alleen-waar-nodig (need-to-know) principe? Waarom is het 
voor een beveiligingssysteem belangrijk zich aan dit principe te houden? 


11.14 Waarom is het moeilijk een systeem te beveiligen waarin gebruikers 
wordt toegestaan hun eigen I/O te verzorgen? 


11.15 Beschikkingsrechtlijsten worden gewoonlijk binnen de adresruimte van 
de gebruiker bewaard. Hoe waarborgt het systeem dat de gebruiker de 
inhoud van de lijst niet kan wijzigen? 
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GRONDBEGINSELEN 
SYSTEEMONTWERPEN 


Het grootste gedeelte van dit boek ging tot nu toe over algoritmen en gegevens- 
structuren voor het oplossen van de specifieke problemen die in besturingssys- 
temen komen kijken. Hoe passen al deze stukken in een besturingssysteem aan 
en in elkaar? In dit hoofdstuk zullen we de problemen bij het ontwerpen en 
implementeren van een besturingssysteem bespreken. Er zijn voor de ontwerp- 
problemen natuurlijk geen volledige oplossingen, maar er zijn benaderingen die 
men met succes heeft beproefd. 


12.1 Doeleinden 


Het eerste probleem bij het ontwerpen van een besturingssysteem is het definië- 
ren van de doeleinden en de specificaties van het systeem. Op het hoogste niveau 
wordt het ontwerp van het systeem aanzienlijk beïnvloed door de keuze van de 
apparatuur en het soort systeem: voor groepsgewijze verwerking (batch), met 
tijddeling (time-sharing), voor één gebruiker, voor meerdere gebruikers, gedistri- 
bueerd, met onvertraagde verwerking (real-time) of voor algemeen gebruik (ge- 
neral purpose). 

Na dit hoogste niveau kan het daarentegen wel eens veel moeilijker zijn de 
eisen te specificeren. De eisen kunnen ruwweg in twee groepen worden verdeeld: 
gebruikersdoeleinden en systeemdoeleinden. 


12.1.1 Gebruikersdoeleinden 


Gebruikers verlangen bepaalde vanzelfsprekende eigenschappen in een systeem. 
Het systeem moet gemakkelijk te leren en te gebruiken, betrouwbaar, veilig en 
snel zijn. Deze specificaties zijn natuurlijk niet erg bruikbaar in het systeemont- 
werp, omdat er geen algemene overeenstemming over bestaat hoe deze doelein- 
den verwezenlijkt moeten worden. 


12.2 Mechanismen en beleid 


12.1.1 Systeemdoeleinden 


Een soortgelijke groep eisen kan worden gedefinieerd door die mensen die het 
systeem moeten ontwerpen, opzetten, onderhouden en bedienen. Het besturings- 
systeem moet gemakkelijk te ontwerpen, te implementeren en te onderhouden 
zijn; het moet flexibel, betrouwbaar, foutvrij en efficiënt zijn. En opnieuw zijn 
deze eisen vaag en bestaat er geen algemene oplossing voor. 

Er is geen unieke oplossing voor het definiëren van de eisen voor een bestu- 
ringssysteem. De brede scala van systemen is er het bewijs van dat verschillende 
eisen kunnen resulteren in een grote verscheidenheid aan oplossingen voor ver- 
schillende omgevingen. De eisen voor bijvoorbeeld CP/M, een microcomputer- 
systeem voor één gebruiker, moeten wel erg veel hebben verschild van die voor 
MVS, het grote besturingssysteem op mainframe-computers van IBM met meer- 
voudige toegang voor meerdere gebruikers. 

Het specificeren en ontwerpen van een besturingssysteem is een in hoge 
mate creatieve taak. De oplossingen zijn niet zomaar in een leerboek te vinden. 
Men heeft echter enkele algemene principes voorgesteld. Programmatuur-tech- 
nologie (Engels: software engineering) is het algemene vak voor deze principes, 
maar sommige ideeën van dit vak zijn speciaal van toepassing op besturingssys- 
temen. 


12.2 Mechanismen en beleid 


Eén zeer belangrijk principe is de scheiding van het beleid van het mechanisme. 
De meeste besprekingen in dit boek concentreerden zich op de mechanismen. 
Mechanismen bepalen hoe iets gedaan moet worden. Het beleid daarentegen be- 
paalt wat er gedaan moet worden. 

Om een voorbeeld te noemen, een algoritme voor CVE-werkindeling op 
grond van prioriteit legt vast hoe de CVE van het ene proces op het andere kan 
worden overgeschakeld. De vaststelling van de prioriteiten voor de processen is 
een beleidsbeslissing. De bespreking in hoofdstuk 11 liet verschillende mechanis- 
men voor het besturen van de toegang tot systeemfaciliteiten zien. Beveiligings- 
mechanismen leveren alleen de middelen voor toegangsbesturing; beleidsbeslis- 
singen moeten uitmaken hoe deze middelen dienen te worden gebruikt. 

De scheiding van beleid en mechanisme is heel belangrijk met het oog op 
flexibiliteit. Het beleid zal waarschijnlijk per plaats en per tijdstip verschillen. In 
het ergste geval zou iedere beleidswijziging een wijziging in het daaraan ten 
grondslag liggende mechanisme vereisen. Een algemeen mechanisme zou wense- 
lijker zijn. Een beleidsverandering vereist dan alleen dat bepaalde systeempara- 
meters opnieuw gedefinieerd worden. 

Beleidsbeslissingen zijn van belang voor alle problemen die verband hou- 
den met het toewijzen van systeemfaciliteiten en met werkindeling. Telkens wan- 
neer het nodig is te bepalen of een systeemfaciliteit moet worden toegewezen of 
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niet, is er sprake van een beleidsbeslissing. 


12.3 Gelaagde aanpak 


Een systeem dat zo groot en complex is als een modern besturingssysteem kan 
alleen worden gemaakt door het in kleinere stukken te verdelen. Elk van deze 
kleinere stukken moet een welomschreven gedeelte van het systeem zijn, met 
zorgvuldig bepaalde invoer, uitvoer en functie. Het in modules opsplitsen kan 
op veel manieren plaatsvinden, maar de aantrekkelijkste manier is de gelaagde 
aanpak. | 

De gelaagde aanpak bestaat hierin dat het besturingssysteem in een aantal 
lagen wordt verdeeld, waarbij elke laag bovenop de onderliggende lagen wordt 
gebouwd. De onderste laag is de apparatuur; de bovenste laag is de koppeling 
met de gebruiker. Dijkstra [1968b] gebruikte de gelaagde aanpak om het THE- 
besturingssysteem te ontwerpen. (De naam wordt gevormd door de initialen van 
de universiteit waaraan hij verbonden was: de Technische Hogeschool te Eindho- 
ven, tegenwoordig Technische Universiteit Eindhoven geheten). Het THE-bestu- 
ringssysteem kende zes lagen, zoals figuur 12.1 laat zien. 

De onderste laag was de apparatuur. De volgende laag was de implementa- 
tie van de CVE-werkindeling als een systeem dat met prioriteiten werkte. De 
prioriteit van ieder proces was een exponentieel gemiddelde van de CVE-tijd, 
berekend over de werkelijke tijd. Deze aanpak gaf 1/O-gebonden jobs een hogere 
prioriteit, zodat deze een snellere dienstverlening ontvingen. 

De volgende laag was de implementatie van het geheugenbeheer. De metho- 
de van geheugenbeheer was paginering (pagina’s van 512 woorden), waarbij een 
trommel als extern geheugen werd gebruikt. Paginering was in de programmatuur 
geïmplementeerd, omdat er geen adresvertaling door de apparatuur aanwezig was 
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Niveau 0: Apparatuur 


Figuur 12.1 © 
Gelaagde structuur van THE 
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ter ondersteuning van paginering. De pagina’s waren daarom in hoge mate zicht- 
baar voor de programmeur. Voor er toegang tot een pagina werd verkregen, werd 
het besturingssysteem aangeroepen om de pagina in het geheugen te brengen. De 
implementatie bevatte een Minst-Recent-Gebruikt (MRG) vervangingsbeleid. Er 
werd van globale vervanging gebruik gemaakt, hoewel pagina’s tijdelijk in het 
geheugen geblokkeerd konden zijn. Het geheugenbeheer was boven de CVE- 
werkindeling gesitueerd, aangezien het noodzakelijk was pagina’s te verwisselen 
door deze uit het geheugen te zetten en weer in het geheugen terug te brengen. 
Gedurende de I/O-tijd nodig om deze overbrenging uit te voeren kon de CVE 
opnieuw worden ingedeeld. | 

Niveau 3 bevatte het stuurprogramma voor het bedieningspaneel van de 
operateur. Door dit, evenals de I/O-buffering, op niveau 4 boven het geheugen- 
beheer te plaatsen, konden de stuurprogramma’s voor de randapparatuur in het 
virtuele geheugen gezet worden. 

De 1/O-buffering bevond zich boven het bedieningspaneel van de opera- 
teur, zodat uitvoer van foutcondities in de I/O naar het bedieningspaneel van de 
operateur kon plaatsvinden. 

Het belangrijkste voordeel van de gelaagde aanpak is een modulaire opbouw. 
De lagen worden op zo’n manier gekozen dat een laag alleen de functies en dien- 
sten van onderliggende lagen gebruikt. Deze aanpak kan het foutvrij maken en 
testen van een systeem heel wat vergemakkelijken. Het eerste niveau kan zonder 
enig bezwaar voor de rest van het systeem getest worden, daar deze laag voor de 
implementatie van zijn functies per definitie alleen gebruik maakt van de basisap- 
paratuur (waarvan we kunnen aannemen dat deze correct werkt). Nadat het eer- 
ste niveau foutvrij is gemaakt, kan de correcte werking daarvan worden aange- 
nomen bij het testen van het tweede niveau, enzovoort. Wordt tijdens het testen 
van een bepaald niveau een fout gevonden, dan weten we dat de fout op dat 
niveau moet zitten, omdat de niveaus daaronder al getest zijn. Door zo het sys- 
teem in lagen te verdelen wordt het ontwerpen en implementeren ervan een stuk 
eenvoudiger. 

Deze aanpak kan op vele manieren worden gebruikt. Het Venus-systeem 
[Liskov 1972a] bijvoorbeeld werd eveneens ontworpen met gebruikmaking van 
een gelaagde aanpak. De lagere niveaus (0 tot en met 4), die de CVE-werkindeling 
en het geheugenbeheer verzorgen, werden in de microcode ondergebracht. Deze 
beslissing bood de voordelen van extra uitvoeringssnelheid en een duidelijk ge- 
definieerde koppeling tussen de niveaus binnen de microcode en de hogere 
niveaus (zie figuur 12.2). 

CP/M maakt ook gebruik van een gelaagd ontwerp (zie figuur 12.3). Omdat 
CP/M een systeem is voor één gebruiker, heeft het hoofdzakelijk te maken met 
stuurprogramma's voor de randapparatuur en het bestandssysteem. De eerste 
programmatuurlaag omvat de stuurprogramma’s voor de randapparatuur. De 
volgende laag bouwt een logisch bestandssysteem op de fysieke stuurprogram- 
ma’s voor de randapparatuur. Tenslotte is de koppeling met de gebruiker, de 
commandovertolker, op het logisch bestandssysteem gebouwd. 
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Figuur 12.2 
Gelaagde structuur van Venus 


De grootste moeilijkheid met de gelaagde aanpak is gelegen in het definië- 
ren van de niveaus. Omdat een laag alleen gebruik kan maken van onderliggende 
lagen, is het noodzakelijk omzichtig te werk te gaan. Het stuurprogramma voor 
het externe geheugen bijvoorbeeld moet op een lager niveau liggen dan de rou- 
tines voor het virtuele geheugen, omdat virtueel geheugen de mogelijkheid vereist 
van het externe geheugen gebruik te maken. 

Andere eisen liggen soms niet zo voor hand. Het stuurprogramma voor het 
externe geheugen zou zich normaal gesproken boven de CVE-werkindeler moeten 
bevinden, omdat het stuurprogramma misschien op I/O moet wachten en de 
CVE dan gedurende deze tijd opnieuw ingedeeld kan worden. Op een groot sys- 
teem kan het echter voorkomen dat de CVE-werkindeler meer programmabestu- 
ringsblokken (PBB’s) heeft dan er in het geheugen kunnen. Daarom kan het nodig 
zijn dat PBB’s in en uit het geheugen gepagineerd worden, wat de eis inhoudt dat 
de besturingsroutine voor het externe geheugen onder de CVE-werkindeler ligt. 


Niveau 3: Gebruikersprogramma’s en commandovertolker 
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Figuur 12.3 
Gelaagde structuur van CP/M 


12.4 Virtuele machines 


Saxena en Bredt [1975] ontwierpen een systeem om een zeer groot aantal 
processen te ondersteunen. Hun systeem had vier niveaus die te maken hadden 
met het beheer van de CVE en van het geheugen. Het laagste niveau werd gele- 
verd door het fysieke geheugen. Het volgende niveau maakte gebruik van het 
fysieke geheugen om de toestand van een vast aantal processen weer te geven. 
Deze opzet maakte het mogelijk dat het volgende niveau uit die processen be- 
stond die nodig zijn om virtueel geheugen te implementeren. Dit virtuele geheu- 
gen werd dan gebruikt om het grote aantal PBB’s op te bergen dat nodig is voor 
een willekeurig aantal processen. Een algemene CVE-werkindeler werd vervol- 
gens in het virtuele geheugen geïmplementeerd. 

De eis dat een laag alleen van onderliggende lagen gebruik kan maken kan 
bij het ontwerpen van een systeem een erg lastige beperking vormen. Dit was 
bijvoorbeeld een belangrijk ontwerpprobleem bij het SUE-systeem [Sevick 1972]. 
Daar staat tegenover dat het opheffen van deze beperking de mogelijkheid schept 
dat er oneindige recursie en oneindige lussen optreden. Zonder deze beperking 
kunnen hogere niveaus lagere niveaus aanroepen die op hun beurt het hogere 
niveau weer aanroepen, die dan het lagere niveau weer aanroept, enzovoort. 


12.4 Virtuele machines 


Een bijzonder interessante ontwerptoepassing van de gelaagde aanpak is het be- 
grip ‘virtuele machine’. Het VM-besturingssysteem voor IBM-systemen is het 
beste voorbeeld van het begrip virtuele machine. 

Door gebruik te maken van CVE-werkindeling en technieken van virtueel 
geheugen kan een besturingssysteem de illusie wekken dat meerdere processen 
elk op hun eigen processor, met hun eigen (virtuele) geheugen, tegelijk worden 
uitgevoerd. Gewoonlijk heeft een proces nog andere mogelijkheden, zoals sys- 
teemaanroepen en een bestandssysteem, waarin niet door de kale apparatuur 
wordt voorzien. De virtuele-machinebenadering daarentegen geeft geen extra 
functie, maar een koppeling die identiek is aan die met de kale apparatuur. Elk 
proces krijgt een (virtuele) kopie van de onderliggende computer. 

De systeemfaciliteiten van de fysieke computer worden gemeenschappelijk 
gebruikt om de virtuele machines te produceren. Om de CVE te delen en het zo 
te laten lijken alsof iedere gebruiker zijn eigen processor heeft kan CVE-werkin- 
deling worden gebruikt. Pagineren op verzoek kan elke (virtuele) processor zijn 
eigen (virtuele) geheugen geven. Het virtuele geheugen voor een virtuele machine 
kan in feite groter of kleiner zijn dan het fysieke geheugen van de fysieke machi- 
ne. Spool-verwerking en een bestandssysteem kunnen virtuele kaartlezers en vir- 
tuele regeldrukkers leveren. Een gewone gebruikersterminal met tijddeling dient 
als het operateur-bedieningspaneel van de virtuele machine. 

De enige echte moeilijkheid zit in de schijvensystemen. Stel dat de fysieke 
machine drie schijf-stuurprogramma’s heeft, maar zeven virtuele machines wil 
ondersteunen. Het is zonder meer duidelijk dat niet aan iedere virtuele machine 
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een magneetschijfeenheid toegewezen kan worden. Denk eraan dat de program- | 
matuur voor de virtuele machine zelf een aanzienlijke hoeveelheid schijfruimte 
nodig zal hebben om de functies van virtueel geheugen en spool-verwerking te 
leveren. De oplossing ligt in het zorgen voor virtuele schijfeenheden die in alle 
opzichten, behalve in grootte, identiek zijn. Deze worden voor het VM-bestu- 
ringssysteem van IBM ’minischijfjes’ (Engels: ’minidisks’) genoemd. Elk mini- 
schijfje wordt geimplementeerd door het aantal benodigde sporen toe te wijzen 
op de fysieke schijven. Uiteraard moet de som van de grootten van alle mini- 
schijfjes kleiner zijn dan de werkelijke hoeveelheid beschikbare fysieke schijf- 
ruimte. 

Op deze wijze krijgen gebruikers hun eigen virtuele machine. Zij kunnen 
dan op hun virtuele machine ieder gewenst stuk programmatuur draaien. Op 
het VM-systeem van IBM draait een gebruiker gewoonlijk CMS, een interactief 
besturingssysteem voor één gebruiker. Daarom ziet de gebruiker een systeem 
voor één gebruiker draaien op een virtuele machine. De programmatuur voor 
virtuele machines heeft tot taak meerdere virtuele machines op één fysieke machi- 
ne te multiprogrammeren, zonder dat daarbij gelet hoeft te worden op de pro- 
grammatuur die dient ter ondersteuning van de gebruiker. Deze opzet kan bij het 
probleem van het ontwerpen van een interactief systeem voor meerdere gebrui- 
kers een heel nuttige splitsing in kleinere stukken geven. 

Hoewel het begrip ’virtuele machine’ heel nuttig is en aan populariteit wint, 
is het erg moeilijk te implementeren. De moeilijkheid schuilt in het leveren van 
een exact duplicaat van de onderliggende machine. U herinnert zich bijvoorbeeld 
wel dat de onderliggende machine twee verwerkingswijzen kent: de gebruiker- 
modus en de monitor-modus. De programmatuur voor virtuele machines kan in 
de monitor-modus draaien, omdat het onderdeel is van het besturingssysteem. 
De virtuele machine zelf kan alleen in de gebruiker-modus draaien. Echter, pre- 
cies zoals de fysieke machine twee verwerkingswijzen heeft, moet de virtuele ma- 
chine die ook hebben. Dit heeft tot gevolg dat we een virtuele gebruiker-modus 
en een virtuele monitor-modus moeten hebben, die beide in een fysieke gebrui- 
ker-modus draaien. Die acties die een overdracht van de gebruiker-modus naar 
de monitor-modus veroorzaken (zoals een systeemaanroep of een poging om een 
bevoorrechte instructie uit te voeren), moeten op een virtuele machine eveneens 
een overdracht van virtuele gebruiker-modus naar virtuele monitor-modus ver- 
oorzaken. 

Deze overdracht kan in het algemeen vrij gemakkelijk tot stand worden 
gebracht. Wanneer bijvoorbeeld een systeemaanroep plaatsvindt door een pro- 
gramma dat op een virtuele machine in virtuele gebruiker-modus draait, zal deze 
systeemaanroep in de reële machine een overdracht naar de monitor van de vir- 
tuele machine bewerkstelligen. De virtuele gebruiker-modus is ook een fysieke 
gebruiker-modus. Wanneer de monitor van de virtuele machine de besturing 
krijgt, kan deze de inhoud van de registers en de programmateller voor de virtuele 
machine wijzigen om het effect van de systeemaanroep te simuleren. Hij kan dan 
de virtuele machine opnieuw starten, waarbij hij weet’ dat deze nu in de monitor- 
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modus is. Als de virtuele machine dan bijvoorbeeld probeert om van zijn virtuele 
kaartlezer te lezen, voert deze een bevoorrechte I/O-instructie uit. Aangezien de 
virtuele machine in de fysieke gebruiker-modus draait zal deze instructie een val 
naar de monitor van de virtuele machine openzetten. De monitor van de virtuele 
machine moet dan het effect van de I/O-instructie simuleren. Eerst zoekt hij het 
spool-verwerkingsbestand op dat de implementatie vormt van de virtuele kaart- 
lezer. Dan vertaalt hij de leesbewerking van de virtuele kaartlezer in een lees- 
bewerking van het spool-verwerkingsbestand op schijf en brengt hij het volgende 
virtuele kaartbeeld’ in het virtuele geheugen van de virtuele machine. Tenslotte 
kan hij de virtuele machine opnieuw starten. De toestand van de virtuele machine 
is exact zo gewijzigd alsof de I/O-instructie was uitgevoerd met een reële kaart- 
lezer voor een reële machine die in een reële monitor-modus draait. 

Het belangrijkste verschil is natuurlijk: tijd. Terwijl de reële I/O misschien 
100 milliseconden geduurd zou hebben, zou de virtuele I/O wel eens minder tijd 
kunnen kosten (omdat deze spool-verwerkt is) of meer tijd (omdat deze vertolkt 
wordt). Bovendien wordt de CVE multigeprogrammeerd over vele virtuele machi- 
nes, waardoor het onvoorspelbaar is hoeveel langzamer de virtuele machines zul- 
len draaien. In het extreme geval kan het nodig zijn alle instructies te simuleren 
om een echte virtuele machine op te leveren. VM werkt voor IBM-machines om- 
dat normale instructies voor de virtuele machines rechtstreeks op de apparatuur 
kunnen worden uitgevoerd. Alleen de bevoorrechte instructies (die hoofdzakelijk 
voor I/O nodig zijn) moeten worden gesimuleerd en veroorzaken daarom een 
vertraging in de uitvoering. 

Het begrip virtuele machine heeft verschillende voordelen. Let erop dat er 
volledige beveiliging is. Elke machine is volledig geïsoleerd van alle andere virtue- 
le machines, zodat er geen beveiligingsprobleem is. Daar staat tegenover dat er 
ook geen gemeenschappelijk gebruik wordt gemaakt van systeemfaciliteiten. Er 
zijn twee manieren geïmplementeerd om toch in gemeenschappelijk gebruik te 
voorzien. Ten eerste is het mogelijk gemeenschappelijk gebruik te maken van een 
minischijfje. Voor deze manier staat het gemeenschappelijk gebruik van een fysie- 
ke schijf model, maar dan wel geïmplementeerd in de programmatuur. Met deze 
techniek kunnen bestanden gemeenschappelijk worden gebruikt. Ten tweede is 
het mogelijk een netwerk van virtuele machines te definiëren, waarbij elke virtue- 
le machine informatie door het virtuele communicatienetwerk kan sturen. Ook 
hierbij staan fysieke communicatinetwerken model voor het virtuele netwerk, 
hoewel dit laatste in de programmatuur is geïmplementeerd. 

Zo’n virtuele-machinesysteem is een uitstekend middel voor het onderzoek 
en de ontwikkeling van besturingssystemen. Normaal gesproken is het wijzigen 
van een besturingssysteem een moeilijk proces. Omdat besturingssystemen grote 
en complexe programma’s zijn, is het moeilijk er zeker van te zijn dat een wij- 
ziging op één plaats geen verborgen fouten in een ander deel kan veroorzaken. 
Deze situatie kan vooral gevaarlijk zijn wegens de kracht van een besturingssys- 
teem. Omdat het besturingssysteem in de monitor-modus werkt, zou een verkeer- 
de verandering in een wijzer een fout teweeg kunnen brengen die het hele be- 
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standssysteem ruïneert. Daarom is het noodzakelijk dat alle wijzigingen in het 
besturingssysteem zorgvuldig getest worden. 

Maar het besturingssysteem draait op, en bestuurt, de gehele machine. 
Daarom moet het huidige systeem tijdens het aanbrengen en testen van wijzigin- 
gen buiten bedrijf worden gesteld. Dit wordt gewoonlijk tijd voor systeemontwik- 
keling genoemd. Daar gedurende deze tijd het systeem niet beschikbaar is voor 
de gebruikers, wordt de tijd voor systeemontwikkeling dikwijls ’s nachts of in de 
weekeinden op het rooster gezet. 

Een virtuele-machinesysteem kan het grootste gedeelte van dit probleem 
uit de wereld helpen. Systeemprogrammeurs krijgen hun eigen virtuele machine 
en nu wordt de systeemontwikkeling op de virtuele machine gedaan, in plaats 
van op een fysieke machine. De normale werking van het systeem hoeft dan 
zelden te worden onderbroken voor systeemontwikkeling. 


12.5 Multiprocessoren 


Tot nu toe was het grootste gedeelte van dit boek gewijd aan systemen voor één 
processor, aangezien de meeste systemen voor één processor bestemd blijken te 
zijn. We zien echter om diverse redenen een tendens in de richting van steeds 
meer multiprocessorsystemen. Eén voordeel daarvan is de doorvoercapaciteit. 
Door het aantal processoren op te voeren hopen we dat er in een kortere tijd 
meer werk klaar komt. Bij n processoren is de versnellingsfactor evenwel niet n, 
maar minder dan n. Wanneer meerdere processoren aan een taak werken is er 
een zekere hoeveelheid overhead nodig om alles correct te laten verlopen. Deze 
overhead, plus de ’strijd’ om systeemfaciliteiten, doet de verwachte winst die uit 
extra processoren behaald kan worden dalen. 

Een andere reden voor multiprocessorsystemen is de betrouwbaarheid. Als 
functies goed over verschillende processoren kunnen worden verdeeld, zal het 
uitvallen van één processor het systeem niet tot staan brengen, maar het alleen 
vertragen. Als we tien processoren hebben en één ervan uitvalt, moet elk van de 
overblijvende processoren een deel van het werk van de uitgevallen processor 
overnemen. Op die manier draait het gehele systeem alleen maar 10 procent lang- 
zamer, in plaats dat het volledig stil komt te liggen. Dit vermogen om door te 
gaan ondanks het optreden van storingen in de apparatuur wordt elegante degra- 
datie (Engels: graceful degradation) genoemd. Systemen die voor elegante degra- 
datie ontworpen zijn worden ook wel systemen met verminderde werking (Engels: 
fail-soft of soft fail) genoemd. 

Het doorgaan van de verwerking ondanks storingen vereist een mechanisme 
voor het ontdekken van de storing, het vaststellen van de aard ervan en corrige- 
rende actie. Het Tandem-systeem maakt gebruik van een duplicaat van zowel de 
apparatuur als de programmatuur om te garanderen dat de verwerking ondanks 
fouten kan doorgaan. Het systeem bestaat uit twee identieke processoren, waarbij 
elk zijn eigen lokale geheugen heeft. De processoren zijn door een hoofdlijn (En- 
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gels: bus) met elkaar verbonden. De ene processor is de hoofdprocessor en de 
andere is de reserveprocessor. Van elk proces worden twee kopieën bijgehouden; 
één in de hoofdprocessor en één in de reserveprocessor. Op vaste controlepunten 
in de verwerking van het systeem wordt alle toestandsinformatie van een proces 
(inclusief een kopie van het geheugenbeeld) van de hoofdmachine naar de reser- 
vemachine gekopieerd. Wordt er een storing ontdekt, dan wordt de kopie op de 
reservemachine geactiveerd en vanaf het recentste controlepunt opnieuw gestart. 

Het ontwerpen van een multiprocessorsysteem is moeilijker dan het ont- 
werpen van een systeem voor één processor. De vroegste multiprocessorsystemen 
gebruikten een meester/slaaf-verwerkingswijze. Eén processor, die als de hoofd- 
processor (meester) was aangewezen, deelde het werk in van de bijprocessoren 
(slaven). Deze opzet heeft gespecialiseerde functies tot gevolg en is heel gebruike- 
lijk. 

Bijvoorbeeld, in een groot systeem met tijddeling bestaat een van de meest 
tijdrovende activiteiten uit het gewoon verwerken van de invoer en uitvoer van 
tekens tussen de terminals en de computer. Als de hoofdprocessor voor elk teken 
van elke terminal onderbroken moet worden, kan deze al zijn tijd wel spenderen 
aan het voortdurend verwerken van tekens. Om deze situatie te vermijden hebben 
de meeste systemen een front-end-processor die alle in- en uitvoer van en naar 
de terminals afhandelt. Een groot IBM-systeem zou bijvoorbeeld een Serie/1- 
minicomputer van IBM als front-end-machine kunnen gebruiken. De front-end- 
machine vervult de rol van een buffer tussen de terminals en de hoofdprocessor, 
zodat de hoofdprocessor de gelegenheid krijgt te werken met regels en blokken 
tekens in plaats van met afzonderlijke tekens. 

Naarmate microprocessors goedkoper en krachtiger worden, kunnen nog 
meer besturingssysteemfuncties overgelaten worden aan bijprocessoren. Het zou 
bijvoorbeeld tamelijk gemakkelijk zijn een microprocessor met zijn eigen geheu- 
gen toe te voegen om een schijvensysteem te beheren. De microprocessor zou een 
reeks verzoeken van de hoofdprocessor kunnen ontvangen en zijn eigen schijf- 
wachtrij en algoritme voor werkindeling kunnen implementeren. Deze regeling 
zou de hoofdprocessor ontlasten van de overhead van de schijf-werkindeling. 

De meester/slaaf-ontwerpstructuur heeft echter zijn beperkingen. Hoewel 
deze de efficiëntie van het systeem kan verhogen, vermindert het de betrouwbaar- 
heid van het systeem wegens de toenemende specialisatie. Een andere aanpak 
bestaat uit het gebruiken van meerdere afzonderlijke identieke processoren. Elke 
processor draait met zijn eigen afzonderlijke kopie van het besturingssysteem. 
Deze methode vergroot de algehele beschikbaarheid van het systeem. De efficién- 
tie kan nu echter wel te lijden hebben. Aangezien ieder systeem volledig op zich- 
zelf staat, kan het ene systeem niets staan te doen en op werk wachten, terwijl 
een ander systeem overladen is met werk. 

Om deze inefficiëntie te vermijden kunnen de processoren gemeenschappe- 
lijk gebruik maken van bepaalde gegevensstructuren, zoals de job-tabel, de toe- 
wijzingssituatie van systeemfaciliteiten en het bestandssysteem. Een multiproces- 
sorsysteem van dit type zal toestaan dat jobs en systeemfaciliteiten dynamisch 
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gemeenschappelijk worden gebruikt door de verschillende processoren en kan de 
variantie tussen de systemen verminderen. Zo’n systeem moet echter wel heel 
zorgvuldig geschreven worden wegens de gemeenschappelijk gebruikte gegevens- 
structuren. Zoals we in hoofdstuk 9 hebben gezien, moet een gegevensstructuur 
die door parallel-verwerkte processen gemeenschappelijk gebruikt wordt met 
zorg worden geprogrammeerd om tijdafhankelijke fouten te vermijden. Het ont- 
werp en de constructie van multiprocessor-besturingssystemen is nog steeds meer 
een kunst dan een wetenschap. 


12.6 Implementatie 


Is een besturingssysteem eenmaal ontworpen, dan moet het worden geimplemen- 
teerd. Het is lange tijd gebruikelijk geweest dat besturingssystemen geschreven 
werden in de assembleertaal. Dit is echter in het algemeen niet langer het geval. 
Besturingssystemen kunnen nu in hogere programmeertalen geschreven worden 
(zoals in hoofdstuk 10 is beschreven). 

Het eerste systeem dat niet in de assembleertaal werd geschreven was waar- 
schijnlijk het Master Control Program (MCP) voor de computers van Burroughs. 
MCP werd geschreven in een variant van ALGOL. Multics, dat op het MIT werd 
ontwikkeld, werd hoofzakelijk in PL/I geschreven. Het Unix-besturingssysteem 
werd voornamelijk in C geschreven. Slechts zo’n 900 regels code werden in de 
assembleertaal geschreven, waarvan het merendeel werd gevormd door het ver- 
deelprogramma en de stuurprogramma’s voor de randapparatuur. Het bestu- 
ringssysteem Primos voor Prime-computers werd in een dialect van FORTRAN 
geschreven. Het SOLO-besturingssysteem is geschreven in Concurrent Pascal. 

De voordelen van het gebruik van een hogere programmeertaal, of althans 
een systeemimplementatietaal, voor het implementeren van besturingssystemen 
zijn dezelfde als voor toepassingsprogramma’s: de code kan sneller geschreven 
worden, is compacter en is gemakkelijker te begrijpen en te testen. Het grootste 
nadeel ligt in de snelheid en de geheugenbehoeften. Hoewel het waar is dat geen 
enkel compileerprogramma constant betere code kan produceren dan een ervaren 
assembleertaal-programmeur, kan een compileerprogramma waarschijnlijk code 
produceren die minstens zo goed is als de code die de gemiddelde assembleertaal- 
programmeur schrijft. Bovendien kan bij vervanging van het compileerprogram- 
ma door een beter de code voor het gehele besturingssysteem over de hele linie 
verbeterd worden door dit gewoon opnieuw te compileren. 

Evenals dat met andere systemen het geval is, zijn aanzienlijke verbeterin- 
gen in het prestatievermogen waarschijnlijk eerder het gevolg van betere ge- 
gevensstructuren en algoritmen dan van schoner coderen. Bovendien is, hoewel 
besturingssystemen heel grote systemen zijn, alleen een kleine hoeveelheid code 
van kritiek belang voor een hoog prestatievermogen; de routine voor het behan- 
delen van paginafouten, de CVE-werkindeler en het verdeelprogramma zijn 
waarschijnlijk de routines waar het het meest op aankomt. Als het systeem ge- 
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schreven is en correct werkt, kunnen routines die stagnatie veroorzaken worden 
opgespoord en vervangen. 

Om deze knelpunten te kunnen identificeren moet het mogelijk zijn het 
prestatievermogen van het systeem te observeren. Men moet code toevoegen om 
metingen van het systeemgedrag te berekenen en weer te geven. In een aantal 
systemen wordt dit gedaan door op magneetband detailverslagen van het gedrag 
van het systeem te produceren. Alle belangwekkende gebeurtenissen worden te- 
zamen met het tijdstip waarop deze plaatsvinden en de belangrijke parameters 
geregistreerd en naar een bestand of magneetband geschreven. Later kan dan een 
analyseprogramma het registratiebestand verwerken om het prestatievermogen 
van het systeem te bepalen en routines op te sporen waarin stagnaties voorkomen 
en die inefficiënt zijn. Dezelfde magneetband-detailverslagen zouden ook als in- 
voer kunnen dienen voor een simulatie van een voorgestelde verbetering van het 
systeem. Detailverslagen op magneetband kunnen ook nuttig zijn voor het vinden 
van fouten in het gedrag van een besturingssysteem. 

Een andere mogelijkheid is de onvertraagde berekening en weergave van 
metingen van het prestatievermogen. Deze opzet kan de systeemoperateurs de 
gelegenheid geven beter vertrouwd te raken met het gedrag van het systeem en 
de werking ervan te wijzigen wanneer het systeem in bedrijf is. 


12.7 Het genereren van systemen 


Het is mogelijk een besturingssysteem speciaal voor één machine op een bepaalde 
locatie te ontwerpen, te coderen en te implementeren. Het is echter gebruikelijker 
dat besturingssystemen worden ontworpen om op iedere machine van een groep 
machines, op tal van locaties en met een verscheidenheid aan randapparatuur te 
draaien. Het systeem moet dan voor iedere specifieke computerlocatie worden 
geconfigureerd of gegenereerd. Dit proces staat bekend als systeemgeneratie 
(SYSGEN). 

Het besturingssysteem wordt gewoonlijk verstuurd op magneetband of op 
schijf. Om een systeem te genereren wordt een speciaal programma gebruikt. Het 
systeemgeneratie-programma vraagt de operateur om informatie aangaande de. 
specifieke configuratie van de apparatuur van het systeem, of leest deze van een 
bestand: 


@ Welke CVE moet worden gebruikt? Welke opties (uitgebreide instructieset, 
drijvende-komma-berekening, enzovoort) worden geïnstalleerd? Voor syste- 
men met meer dan één CVE moet iedere CVE worden omschreven. 

@ Hoeveel geheugen is beschikbaar? Sommige systemen zullen deze hoeveelheid 
zelf bepalen door naar alle geheugenplaatsen te verwijzen tot er een ‘ongeldig 
adres’-fout wordt gegenereerd. Deze procedure definieert het laatste legale 
adres en daaruit de hoeveelheid beschikbaar geheugen. 

@ Welke randapparatuur is beschikbaar? Het systeem zal moeten weten hoe elk 
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apparaat geadresseerd moet worden (zijn apparaatnummer), waar onder- 
brekingen door het apparaat plaatsvinden, het type en het model, en speciale 
eigenschappen. 

@ Welke besturingssysteemopties zijn gewenst of welke parameterwaarden moe- 
ten worden gebruikt? Hierin zouden begrepen kunnen zijn hoeveel buffers van 
welke grootte gebruikt moeten worden, welk algoritme voor CVE-werkinde- 
ling verlangd wordt, het maximumaantal processen dat ondersteund moet 
worden, het tijd-quantum voor werkindeling bij toerbeurt, enzovoort. 


Is deze informatie eenmaal gedefinieerd, dan kan deze op verschillende manie- 
ren worden gebruikt. Het ene uiterste geval is dat deze wordt gebruikt om een 
kopie van de bronversie van het besturingssysteem te wijzigen. Het besturingssys- 
teem is dan volledig gecompileerd. Gegevensdeclaraties, initialiseringscode en 
constanten, tezamen met voorwaardelijke compilering, produceren als uitvoer 
een werkversie van het besturingssysteem die voor het omschreven systeem pre- 
cies op maat gemaakt is. 

Op een wat minder pasklaar niveau kunnen op grond van de systeem- 
beschrijving tabellen worden gecreëerd en modulen worden geselecteerd uit een 
van tevoren gecompileerde bibliotheek. Deze modulen worden dan met elkaar 
verbonden tot het gegenereerde besturingssysteem. Door van selectie gebruik te 
maken is het mogelijk dat de bibliotheek de stuurprogramma’s voor alle onder- 
steunde randapparatuur bevat, maar dat alleen die programma’s die werkelijk 
nodig zijn met het besturingssysteem worden verbonden. Omdat niets van het 
besturingssysteem opnieuw gecompileerd wordt is de systeemgeneratie sneller, 
hoewel er een systeem uit kan ontstaan dat wat algemener is dan echt nodig zou 
zijn. 

Het andere uiterste is dat men een systeem bouwt dat volledig met behulp 
van tabellen bestuurd wordt. De gehele code is dan altijd een onderdeel van het 
systeem, waarbij de selectie plaatsvindt tijdens de uitvoering, niet bij het compile- 
ren of monteren. Systeemgeneratie is dan niets anders dan het opzetten van de 
juiste tabellen om het systeem te omschrijven. 

De belangrijkste verschillen tussen deze methoden worden gevormd door 
de omvang en de algemeenheid van het gegenereerde systeem en het gemak waar- 
mee wijzigingen kunnen worden aangebracht bij veranderingen in de samenstel- 
ling van de apparatuur. Kijk eens wat het kost om het systeem te wijzigen zodat 
het een nieuwe grafische terminal of een andere schijfeenheid kan ondersteunen. 
Tegen die kosten moet men natuurlijk afwegen hoe vaak (of hoe weinig) zulke 
wijzigingen moeten plaatsvinden. 


12.8 Samenvatting 


Het ontwerpen van een nieuw besturingssysteem is een hele opgave. Het is van 
groot belang dat de doeleinden waaraan het systeem dient te beantwoorden goed 


Opgaven 


worden omschreven voordat men met het ontwerpen begint. Het soort systeem 
dat gewenst is vormt de basis voor de keuzen tussen de verschillende algoritmen 
en strategieën die nodig zullen zijn. 

Daar een besturingssysteem erg groot is, is een modulaire opbouw heel be- 
langrijk. Het ontwerpen van een besturingssysteem als een reeks lagen wordt als 
een belangrijke ontwerptechniek gezien. De virtuele machine is een bijzondere 
vorm van de gelaagde aanpak die de problemen van het ontwerpen van een kop- 
peling met de gebruiker gescheiden kan houden van die van het leveren van een 
systeem met multiprogrammering. 

Besturingssystemen worden nu bijna altijd geschreven in een systeemimple- 
mentatietaal of een hogere programmeertaal. Deze voorziening betekent een ver- 
betering voor de implementatie, het onderhoud en de overdraagbaarheid van be- 
sturingssystemen. Voor het produceren van het besturingssysteem voor een spe- 
ciale machineconfiguratie is systeemgeneratie nodig. 


Opgaven 


12.1 Beschrijf de volgende componenten van besturingssystemen: 
a. geheugenbeheer. 
b. CVE-werkindeling. 
c. adresboek van het bestandssysteem. 
d. overwegingen aangaande impasses. | 
voor een interactief basissysteem voor speciale toepassingen (zoals APL 
of BASIC) dat met tijddeling werkt en niet meer dan één paar grensregis- 
ters heeft (één boven- en één ondergrens). 


12.2 Welke veranderingen in het ontwerp zouden zich voordoen in het sys- 
teem van opgave 12.1 in geval van twee paar grensregisters? 


12.3 Iemand heeft eens een besturingssysteem omschreven als”... die grote 
geheugenballast die door een nadenkende fabrikant wordt bijgeleverd 
om grote hoeveelheden processortijd te gebruiken voor het vertragen van 
de normale werkdoorvoer!’ Beschrijf voor elk van de volgende modulen 
wat de overhead van een bestandssyteem rechtvaardigt: een I/O-systeem, 
een job-besturingssysteem, besturing van het bedieningspaneel, geheu- 
genbeheer en CVE-werkindeling. 


12.4 Als besturingssystemen in werkelijkheid altijd de besturingsmechanismen 
(dat wil zeggen toezicht- en besturingsfuncties) van onze computersys- 
temen geweest zijn, wat zijn dan enkele van de specifieke besturingspro- 
blemen in besturingssystemen wanneer we die zien als programma’s voor 
CVE-werkindeling en geheugenbeheer? 
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12.5 Wat is de volgorde van de volgende lagen van een gelaagd besturingssys- 
teem? 

beheer van het in pagina’s or geheugen. 

. CVE-werkindeling. 

werkindeling en afhandeling van de I/O. 

. Pascal-compileerprogramma. 

e. besturingskaartvertolker. 

Ga ervan uit dat het laagste niveau de apparatuur en het hoogste niveau 

de gebruiker is. 


ane 


12.6 Stel dat u een besturingssysteem met tijddeling, dat BASIC en APL on- 
dersteunt, moet ontwerpen voor studenten in de techniek. Het systeem 
is uitgerust met 32 beeldstations met vaste bedrading, een regeldrukker 
en twee grote schijven met bewegende lees/schrijfkoppen. De appara- 
tuur ondersteunt de gebruiker- en monitor-modus, bevoorrechte I/O- 
instructies en apparatuur voor het beheer van het in pagina’s verdeelde 
geheugen. Beschrijf in het kort hoe u de volgende problemen zou aan- 
pakken: 

a. CVE-werkindeling. 

b. geheugenbeheer. 

c. schijf-werkindeling. 

d. bestandssysteem. 

e. gebruikersidentificatie en beveiliging van de toegangsbesturing. 

f. impasses. 


12.7 Vergelijk de verschillende organisaties van besturingssystemen ten be- 
hoeve van multiprocessorsystemen en bespreek de verschillen. 


12.8 Waarom is het noodzakelijk meer dan één processor te hebben in een 
systeem met verminderde werking (fail-soft)? 


12.9 Wat is eenvoudiger bij virtuele machines: een kopie leveren van de host- 
machine (letterlijk: ’gastheermachine’) of van een willekeurige machine? 
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GEDISTRIBUEERDE SYSTEMEN 


Een nieuwe ontwikkeling in computersystemen is het distribueren van de verwer- 
king over verschillende fysieke processoren. In principe zijn er twee methoden 
voor het bouwen van zulke systemen. In een sterk-gekoppeld systeem maken de 
processoren gemeenschappelijk gebruik van het geheugen en een klok. In deze 
multiprocessorsystemen vindt de communicatie gewoonlijk plaats via het gemeen- 
schappelijk gebruikte geheugen (hoofdstuk 9). 

In een zwak-gekoppeld systeem maken de processoren geen gemeenschap- 
pelijk gebruik van het geheugen of een klok. De processoren communiceren dan 
met elkaar door middel van verschillende communicatielijnen, zoals snelle hoofd- 
verbindingen of telefoonlijnen. Deze systemen worden gewoonlijk aangeduid als 
gedistribueerde systemen. 

In dit hoofdstuk houden we ons bezig met gedistribueerde systemen. We 
stellen de belangrijkste verschillen tegenover elkaar in het besturingssysteemont- 
werp tussen deze soorten systemen en de gecentraliseerde systemen die we in het 
voorgaande hebben behandeld. 


13.1 Beweegredenen 


De processoren in een gedistribueerd systeem kunnen verschillen in omvang en 
in functie. Er kan sprake zijn van microprocessoren, werkstations, minicomputers 
en grote computersystemen voor algemene doeleinden. Deze processoren staan 
bekend onder een aantal verschillende namen, zoals locaties, knooppunten, compu- 
ters, enzovoort, afhankelijk van de context waarin zij worden vermeld. We gebrui- 
ken hoofdzakelijk de term locatie, om de nadruk te leggen op de fysieke spreiding 
van deze systemen. 

Er zijn vier hoofdredenen voor het bouwen van gedistribueerde systemen: 
gemeenschappelijk gebruik van systeemfaciliteiten, snellere verwerking, betrouw- 
baarheid en communicatie. In deze paragraaf gaan we op elk van deze redenen 
dieper in. 


13.1 Beweegredenen 


13.1.1 Gemeenschappelijk gebruik van systeemelementen 


Als een aantal verschillende locaties (met verschillende functies) met elkaar ver- 
bonden zijn, kan wellicht een gebruiker in de ene locatie de systeemfaciliteiten 
gebruiken die beschikbaar zijn in een andere locatie. Bijvoorbeeld, het kan zijn 
dat een gebruiker in locatie A gebruik maakt van een laser-printer die alleen op 
locatie B beschikbaar is. Intussen kan een gebruiker in B een bestand benaderen 
dat in A is opgeslagen. In het algemeen levert het gemeenschappelijk gebruik van 
systeemfaciliteiten in een gedistribueerd systeem mechanismen voor het gemeen- 
schappelijk gebruik van bestanden in veraf gelegen locaties, het verwerken van 
informatie in een gedistribueerde database, het afdrukken van bestanden in veraf 
gelegen locaties, het gebruik van gespecialiseerde apparatuur (zoals een snelle 
array-processor) die elders staat opgesteld en andere bewerkingen. 


13.1.2 Snellere verwerking 


Als een bepaalde computerbewerking kan worden gesplitst in een aantal deel- 
bewerkingen die parallel kunnen worden uitgevoerd, dan kunnen we wanneer we 
een gedistribueerd systeem tot onze beschikking hebben de bewerking over de 
verschillende locaties verdelen om deze parallel uit te voeren. Bovendien kunnen, 
als een bepaalde locatie overladen is met werk, sommige jobs naar locaties wor- 
den overgeheveld waar de werkbelasting minder zwaar is. Dit overhevelen van 
jobs heet gedeelde werkbelasting. 


13.1.3 Betrouwbaarheid 


Als in een gedistribueerd systeem een locatie uitvalt, kunnen de overblijvende 
locaties in principe blijven werken. Als het systeem bestaat uit een aantal grote 
autonome installaties (dat wil zeggen, computers voor algemene doeleinden), mag- 
het uitvallen van één ervan niet van invloed zijn op de rest. Als daarentegen het 
systeem is opgebouwd uit een aantal kleine machines, waarbij elk van de machi- 
nes verantwoordelijk is voor een of andere essentiële systeemfunctie, (zoals de 
I/O voor terminal-tekens of het bestandssysteem), kan het uitvallen van één er- 
van in feite de werking van het gehele systeem stopzetten. In het algemeen kan, 
als er genoeg redundantie in het systeem (zowel in de apparatuur als de gegevens) 
bestaat, het systeem blijven werken, zelfs als enkele locaties zijn uitgevallen. 
Het uitvallen van een locatie moet door het systeem ontdekt worden, waar- 
na juiste actie nodig kan zijn om de storing op te heffen. Het systeem moet dan 
niet langer de diensten van die locatie gebruiken. Bovendien moet het systeem, 
als de functie van de uitgevallen locatie door een andere locatie kan worden 
overgenomen, de garantie bieden dat het overnemen van functies op de juiste 
wijze plaatsvindt. Tenslotte moeten er mechanismen beschikbaar zijn om, wan- 
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neer de uitgevallen locatie weer in actie komt of hersteld is, de locatie weer soepel 
in het systeem op te nemen. 


13.1.4 Communicatie 


Wanneer een aantal locaties door een communicatienetwerk met elkaar verbon- 
den zijn, hebben de gebruikers in de verschillende locaties de gelegenheid om 
informatie uit te wisselen. Veel systemen hebben voor dit communicatiesysteem 
het postkantoor als model genomen. In een gedistribueerd systeem duiden we 
een dergelijke activiteit aan als elektronische post. 

ledere gebruiker in het netwerk krijgt een brievenbus, een unieke naam bin- 
nen elke locatie. Een gebruiker kan post sturen naar een andere gebruiker in 
dezelfde of een andere locatie. Post is tekst die niet vertolkt wordt door het bestu- 
ringssysteem. De gebruiker moet een adres opgeven waarnaar de post verstuurd 
kan worden. Een adres is de naam van een brievenbus plus de naam van een 
locatie. (De naam van de locatie kan worden weggelaten bij het communiceren 
binnen eenzelfde locatie.) Wanneer het besturingssysteem post naar zijn bestem- 
ming zendt, hangt het daar ook het adres (de naam van de brievenbus) van de 
afzender aan. Dit retouradres kan worden gebruikt als post niet besteld kan wor- 
den, of als de ontvanger een antwoord naar de afzender wil sturen. 

Post die nog niet is afgeleverd wordt bewaard in een wachtrij die met de 
brievenbus verbonden is. Is een postbericht eenmaal gelezen, dan heeft de gebrui- 
ker de keus uit verschillende mogelijkheden, zoals opslaan voor later gebruik, 
vernietigen, doorsturen naar een andere brievenbus (deze keuze vereist het opzet- 
ten van een nieuw adres), of het sturen van een antwoordbericht naar de oor- 
spronkelijke afzender. Een toepassingsprogramma levert in het algemeen de kop- 
peling tussen de gebruiker en het post-subsysteem. Gebruikers kunnen nieuwe 
post lezen en op hun gemak oude post doornemen. 

De overeenkomst tussen een systeem van elektronische post, dat een toe- 
passing vormt die voor gebruikers zichtbaar is, en een berichtensysteem (zoals 
dat werd besproken in paragraaf 9.8), dat bedoeld is voor communicatie tussen 
processen, is wel opvallend. Een besturingssysteem dat werd ontworpen als een 
verzameling processen die met elkaar communiceren via een berichtensysteem 
(zoals het Accent-systeem), kan gemakkelijk worden uitgebereid tot een gedistri- 
bueerd systeem. 


13.2 Topologie 


De locaties in het systeem kunnen op tal van manieren fysiek verbonden zijn. 
Elke configuratie heeft zijn voor- en nadelen. In het kort beschrijven we enkele 
van de meest gebruikelijke configuraties die tot nu toe zijn geïmplementeerd, en 
vergelijken we ze ten aanzien van de volgende criteria: 
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@ Basisprijs. Hoe duur is het om de verschillende locaties in het systeem met 
elkaar te verbinden? 

@ Communicatiekosten. Hoe lang duurt het om een bericht van locatie A naar 
locatie B te sturen? 

@ Betrouwbaarheid. Als er een verbinding of locatie in het systeem uitvalt, kun- 
nen de overblijvende locaties dan nog met elkaar communiceren? 


De diverse topologieën worden afgebeeld als grafen waarvan de knooppunten 
corresponderen met locaties. Een lijn van knooppunt A naar knooppunt B corres- 
pondeert met een directe verbinding tussen de twee locaties. 


13.2.1 Volledig-verbonden 


In een volledig-verbonden netwerk is iedere locatie direct verbonden met alle 
andere locaties in het systeem (zie figuur 13.1). De basisprijs van deze configura- 
tie is erg hoog, omdat er tussen elke twee locaties een directe verbinding beschik- 
baar moet zijn. De basisprijs groeit kwadratisch met het aantal locaties. In deze 
omgeving kunnen echter de berichten tussen de locaties zeer snel verzonden wor- 
den; een bericht hoeft slechts van één verbinding gebruik te maken om de weg 
tussen elk paar locaties af te leggen. Bovendien zijn zulke systemen zeer betrouw- 
baar, omdat er wel veel verbindingen moeten uitvallen wil het systeem gesplitst 
worden. Een systeem is gepartitioneerd als het gesplitst is in twee (of meer) sub- 
systemen waarvan de locaties niet langer kunnen communiceren met locaties in 
andere subsystemen. 


13.2.2 Gedeeltelijk-verbonden 


In een gedeeltelijk-verbonden netwerk bestaan er directe verbindingen tussen 
sommige, maar niet alle, paren locaties (figuur 13.2). Daarom is de basisprijs van 


Figuur 13.1 
Volledig-verbonden netwerk 
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Figuur 13.2 
Gedeeltelijk-verbonden netwerk 


deze configuratie lager dan die van het volledig-verbonden netwerk. Het is echter 
mogelijk dat een bericht van de ene locatie naar de andere via verschillende tus- 
senlocaties verzonden moet worden, waardoor een langzamere communicatie op- 
treedt. In het systeem dat in figuur 13.2 is afgebeeld bijvoorbeeld moet een be- 
richt van locatie A naar locatie D via de locaties B en C gestuurd worden. 
Bovendien is een gedeeltelijk-verbonden systeem niet even betrouwbaar als 
een volledig-verbonden netwerk. Als één verbinding uitvalt kan het netwerk al 
gepartitioneerd zijn. Als in het voorbeeld van figuur 13.2 de verbinding van B 
naar C uitvalt, is het netwerk in twee subsystemen gepartitioneerd. Het ene sub- 
systeem omvat de locaties A, B en E; het andere subsysteem wordt gevormd door 
de locaties C en D. De locaties in de ene partitie kunnen niet communiceren met 
de locaties in de andere. Om de kans hierop zo klein mogelijk te maken wordt 
iedere locatie gewoonlijk met ten minste twee andere locaties verbonden. Bijvoor- 
beeld, als we een verbinding van A naar D toevoegen, kan het uitvallen van één 
enkele verbinding niet tot gevolg hebben dat het systeem gepartitioneerd wordt. 


13.2.3 Hiërarchie 


In een hiërarchisch netwerk zijn de locaties als een boom georganiseerd (zie fi- 
guur 13.3). Dit is een gebruikelijke organisatie voor computernetwerken van grote 
maatschappijen. De afzonderlijke kantoren worden verbonden met het lokale 
hoofdkantoor. De hoofdkantoren worden weer verbonden met districtskantoren; 
districtskantoren worden tenslotte verbonden met het hoofdkantoor van de 
maatschappij. 

Iedere locatie (behalve de wortel) heeft een unieke ouder en een aantal kin- 
deren. De basisprijs van deze configuratie is in het algemeen lager dan die van 
het gedeeltelijk-verbonden netwerk. In deze omgeving hebben een ouder en een 
kind directe communicatie. Bloedverwanten kunnen alleen met elkaar communi- 
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Figuur 13.3 
Netwerk met boomstructuur 


ceren via hun gemeenschappelijke ouder. Een bericht van de ene bloedverwant 
naar een andere moet omhoog gestuurd worden naar de ouder en dan naar be- 
neden naar de andere bloedverwant. Evenzo kunnen neven alleen met elkaar 
communiceren via hun gemeenschappelijke grootouder. Als een ouderlocatie uit- 
valt kunnen zijn kinderen niet langer met elkaar of met andere processen com- 
municeren. In het algemeen kan het uitvallen van elk knooppunt (af; gezien van 
een blad) het netwerk in verschillende van elkaar gescheiden deelbomen partitio- 
neren. 


13.2.4 Ster 


In een ster-netwerk is één van de locaties in het systeem verbonden met alle 
andere locaties (figuur 13.4). Geen van de andere locaties is met een van de ande- 


Figuur 13.4 
Stervormig netwerk 
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re verbonden. De basisprijs van dit systeem neemt lineair toe met het aantal 
locaties. De communicatiekosten zijn ook laag, aangezien een bericht van locatie 
A naar locatie B ten hoogste tweemaal verstuurd wordt (van A naar de centrale 
locatie en vandaar naar B). Deze snelheid kan echter wel eens wat misleidend 
zijn, omdat de centrale locatie een knelpunt kan gaan vormen. Daarom kan de 
tijd nodig om deze berichten te versturen wel lang zijn, ook al is het aantal overge- 
brachte berichten klein. In veel ster-systemen wordt de centrale locatie daarom 
uitsluitend belast met de taak van het doorschakelen van berichten. 
Als de centrale locatie uitvalt is het netwerk volledig gepartitioneerd. 


13.2.5 Ring 


In een ring-netwerk is iedere locatie fysiek met exact twee andere locaties verbon- 
den (figuur 13.5a). De ring kent eenrichtings- of tweerichtingsverkeer. In een 
architectuur met eenrichtingsverkeer kan een locatie naar slechts één van zijn 
buren informatie overbrengen. Alle locaties moeten informatie in dezelfde rich- 
ting sturen. In een architectuur met tweerichtingsverkeer kan een locatie informa- 
tie naar elk van beide buren sturen. De basisprijs van een ring neemt weer lineair 
toe met het aantal locaties. De communicatiekosten kunnen echter heel hoog zijn. 
Een bericht van de ene locatie naar een andere reist de ring rond tot het zijn 
bestemming bereikt. In een ring met eenrichtingsverkeer zouden daarvoor n—1 
berichten nodig kunnen zijn. In een ring met tweerichtingsverkeer zijn er ten 
hoogste n/2 berichten nodig. 

In een ring met tweerichtingsverkeer moeten er twee verbindingen uitvallen 
wil het netwerk gepartitioneerd worden. In een ring met eenrichtingsverkeer par- 


(a) (b) 


Figuur 13.5 
Ringvormige netwerken met (a) enkele en (b) dubbele verbindingen 
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titioneert het uitvallen van één enkele locatie (of verbinding) het netwerk. Eén 
remedie wordt gevormd door de architectuur uit te breiden door dubbele verbin- 
dingen aan te brengen, zoals figuur 13.5b laat zien. 


13.2.6 Hoofdverbinding met meervoudige toegang 


In een netwerk dat bestaat uit een hoofdverbinding met meervoudige toegang 
(Engels: multi-access bus network) is er één gemeenschappelijke verbinding (de 
‘bus’ of hoofdtransmissielijn). Alle locaties in het systeem zijn direct met die 
transmissielijn verbonden, die als een rechte lijn (figuur 13.6a) of als een ring 
(figuur 13.6b) georganiseerd kan zijn. De locaties kunnen rechtstreeks met elkaar 


(a) 


(b) 


Figuur 13.6 
Netwerk met (a) lineaire en (b) ringvormige hoofdlijn 
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via deze lijn communiceren. De basisprijs van het netwerk hangt lineair af van 
het aantal locaties. De communicatiekosten zijn erg laag, tenzij de hoofdverbin- 
ding een knelpunt wordt. Let erop dat deze topologie van het netwerk lijkt op 
die van het ster-netwerk met een centrale locatie die alleen berichten door- 
schakelt. Het uitvallen van één locatie is niet van invloed op de communicatie 
tussen de rest van de locaties. Als echter de hoofdverbinding uitvalt is het net- 
werk volledig gepartitioneerd. 


13.3 Communicatie 


De ontwerper van een communicatienetwerk moet op vijf fundamentele kwesties 
letten: 


@ Routestrategieën. Hoe worden de berichten door het netwerk gestuurd? 

@ Verbindingsstrategieën. Hoe verzenden twee processen een serie berichten? 

@ Wedijver. Hoe lossen we, waar het netwerk een gemeenschappelijk gebruikte 
systeemfaciliteit is, met elkaar strijdige aanspraken op het gebruik ervan op? 

@ Veiligheidszekerheid. Hoe houden we de inhoud van berichten geheim? 

@ Ontwerpstrategieën. Wat is het algemene ontwerp voor communicatie tussen 
toepassingsprogramma’s? 


In de volgende paragrafen gaan we op elk van deze kwesties nader in. 


13.3.1 Routestrategieén 


Wanneer een proces in locatie A met een proces in locatie B wil communiceren, 
hoe wordt het bericht dan gestuurd? Als er slechts één fysiek pad van A naar B 
loopt (zoals in een stervormig of hiërarchisch netwerk), moet het bericht langs 
dat pad verzonden worden. Als er echter meer fysieke paden van A naar B gaan, 
bestaan er verschillende mogelijkheden om de route te kiezen. Elke locatie heeft 
een routetabel, waarin de alternatieve paden zijn aangegeven die gebruikt kunnen 
worden om een bericht naar andere locaties te zenden. De tabel kan ook informa- 
tie bevatten over de snelheid en de kosten van de verschillende communicatie- 
paden. De tabel kan wanneer nodig worden bijgewerkt. 


@ Vaste routes. Een pad van A naar B wordt van tevoren vastgesteld en dit veran- 
dert niet tenzij een storing in de apparatuur dit pad buiten werking stelt. Ge- 
woonlijk wordt het kortste pad gekozen om de communicatiekosten zo laag 
mogelijk te houden. 

@ Virtueel circuit. Een pad van A naar B is vastgelegd voor de duur van één 
sessie. Als in verschillende sessies berichten van A naar B gaan, kan dat langs 
verschillende paden zijn. 
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@ Dynamische routes. Het pad dat gebruikt wordt om een bericht van A naar B 
te sturen wordt pas gekozen op het moment dat het bericht verstuurd wordt. 
Omdat deze beslissing dynamisch wordt genomen, kunnen afzonderlijke be- 
richten verschillende paden toegewezen krijgen. Locatie A besluit een bericht 
naar locatie C te sturen; C op zijn beurt besluit dit bericht naar D te sturen, 
enzovoort. Uiteindelijk zal een locatie het bericht aan B afgeven. Gewoonlijk 
stuurt een locatie een bericht naar een andere locatie over de lijn die op dat 
bepaalde moment het minst gebruikt wordt. 


Bij het gebruik van deze drie methoden moet men wel eens tot een compro- 
mis besluiten. Vaste routes laten geen aanpassing aan veranderingen in de belas- 
ting toe. Met andere woorden, als eenmaal een pad tussen A en B is vastgesteld, 
moeten de berichten langs dit pad verstuurd worden, zelfs als het pad zwaarbelast 
is terwijl een ander pad licht belast is. Dit probleem wordt voor een deel verhol- 
pen door van virtuele circuits gebruik te maken en kan volledig omzeild worden 
door dynamische routes te gebruiken. Vaste routes en virtuele circuits geven de 
garantie dat berichten van A naar B zullen worden afgeleverd in de volgorde 
waarin ze werden verzonden. Bij dynamische routes kunnen berichten in de ver- 
keerde volgorde aankomen. Dit probleem kan worden verholpen door een volgor- 
denummer aan elk bericht te hechten. 


13.3.2 Verbindingsstrategieën 


Er bestaat een aantal verschillende manieren om processen die via het netwerk 
met elkaar willen communiceren te verbinden. De drie meest gebruikte methoden 
zijn circuitschakeling, berichtenschakeling en pakketschakeling. 


@ Circuitschakeling. Als twee processen met elkaar willen communiceren wordt 
er een permanente verbinding tussen hen gelegd. Deze verbinding wordt voor 
de duur van de communicatie toegewezen en geen ander proces kan die verbin- 
ding gedurende deze periode gebruiken (zelfs als de twee processen een tijdje 
niet actief met elkaar communiceren). Deze opzet is gelijk aan die van het 
telefoonsysteem. Is eenmaal een communicatielijn tussen twee personen ge- 
opend (dat wil zeggen, persoon A belt persoon B op), dan kan niemand anders 
van dit circuit gebruik maken, totdat de communicatie expliciet beëindigd 
wordt (bijvoorbeeld wanneer een van beide partijen ophangt). 

@ Berichtenschakeling. Als twee processen met elkaar willen communiceren, 
wordt er een tijdelijke verbinding tot stand gebracht voor de duur van het 
overbrengen van één bericht. Fysieke verbindingen worden dynamisch aan de 
gebruikers, al naar behoefte, toegewezen voor slechts korte perioden. Elk be- 
richt is een blok gegevens plus wat systeeminformatie (zoals de plaats van 
herkomst, de bestemming en foutherstelcodes) die het communicatienetwerk 
de gelegenheid geven het bericht correct op zijn bestemming af te leveren. 


472 Hoofdstuk 13 Gedistribueerde systemen 


Deze opzet lijkt op die van het brievenstelsel van de PTT. Iedere brief wordt 
als een bericht beschouwd dat zowel het bestemmingsadres als het adres van 
herkomst (retouradres) bevat. Let erop dat veel berichten (van verschillende 
gebruikers) over dezelfde verbinding kunnen worden verstuurd. 

e Pakketschakeling. Gewoonlijk hebben berichten een variabele lengte. Om het 
systeemontwerp te vereenvoudigen wordt de communicatie meestal geïmple- 
menteerd met gebruikmaking van berichtjes met een vaste lengte, die pakketten 
worden genoemd. Het is mogelijk dat één logisch bericht in een aantal pakket- 
ten verdeeld moet worden. Elk pakket kan afzonderlijk naar zijn bestemming 
gestuurd worden en elk pakket kan daarbij een ander pad door het netwerk 
volgen. De pakketten moeten bij aankomst weer tot berichten samengevoegd 
worden. 


Uiteraard kleven er aan elk van deze methoden voor- en nadelen. Circuitschake- 
ling vereist nogal wat insteltijd, maar de overhead van het versturen van elk be- 
richt valt mee. Berichten- en pakketschakeling daarentegen vereisen minder in- 
stellingstijd, maar per verstuurd bericht is er meer overhead. Daar komt bij dat 
bij pakketschakeling elk bericht in pakketten verdeeld en later weer samen- 
gevoegd moet worden. 


13.3.3 Wedijver 


Omdat een verbindingslijn meerdere locaties kan verbinden is het mogelijk dat 
verschillende locaties gelijktijdig informatie over een lijn willen sturen. Deze 
moeilijkheid doet zich voornamelijk voor in een ring-netwerk of een netwerk van 
een hoofdverbinding met meervoudige toegang. In dit geval kan de overgestuurde 
informatie verminkt worden zodat deze weggegooid moet worden. De locaties 
moeten dan over het probleem worden ingelicht, zodat ze de benodigde informa- 
tie opnieuw kunnen versturen. Als geen speciale voorzieningen worden getroffen 
kan deze situatie zich herhalen, wat dan tot gevolg heeft dat het prestatiever- 
mogen terugloopt. Men heeft verschillende technieken bedacht om herhaalde 
botsingen te voorkomen, zoals het signaleren van botsingen, het doorgeven van een 
merkteken (Engels: token passing) en berichtenvakken. 


@ Het signaleren van botsingen. Alvorens een bericht over de lijn te zenden moet 
een locatie luisteren om vast te stellen of op dat moment een ander bericht 
over die lijn verzonden wordt. Als de verbinding vrij is kan de locatie met 
verzenden beginnen. Anders moet de locatie wachten (en luisteren) tot de ver- 
bindingslijn vrij is. Als twee of meer locaties op precies hetzelfde moment 
beginnen te verzenden (waarbij elke locatie denkt dat niemand anders de lijn 
gebruikt), moeten zij ophouden met zenden. Elke locatie probeert het dan na 
een willekeurig tijdje opnieuw. Let erop dat wannneer A over de lijn begint te 
zenden, hij constant moet blijven luisteren om botsingen te signaleren met 
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berichten van andere locaties. Het grote probleem met deze aanpak is dat, 
wanneer het systeem erg druk is, er heel wat botsingen kunnen optreden en zo 
dus het prestatievermogen naar beneden gaat. Deze aanpak is met succes ge- 
bruikt in het Ethernet-systeem [Metcalfe en Boggs 1976]. 

@ Het doorgeven van een merkteken. Een uniek soort bericht, dat bekend staat 
als een merkteken, circuleert constant in het systeem (gewoonlijk is dat een 
ringstructuur). Een locatie die informatie wil verzenden moet wachten tot het 
merkteken aankomt. Hij neemt het merkteken uit de ring en begint zijn berich- 
ten te verzenden. Wanneer de locatie klaar is met het doorgeven van berichten 
verstuurt hij het merkteken opnieuw. Deze actie zal op zijn beurt een andere 
locatie de gelegenheid geven het merkteken te bemachtigen en met het verzen- 
den van berichten te beginnen. Als het merkteken ergens zoek raakt, moet het 
systeem dit ontdekken en een nieuw merkteken produceren. Het merkteken 
wordt gewoonlijk geproduceerd door een verkiezing te houden. Deze heeft tot 
doel een unieke locatie uit te kiezen. De gekozen locatie laat het merkteken 
dan opnieuw rondgaan. In paragraaf 13.12 geven we een verkiezingsalgoritme. 
Een manier voor het doorgeven van een merkteken is gevolgd in Primenet 
[Nelson en Gordon 1978]. 

@ Berichtenvakken. Een aantal berichtenvakken met een vaste lengte circuleert 
constant in het systeem (gewoonlijk een ringstructuur). Elk vak kan een bericht 
met een vaste lengte bevatten plus wat besturingsinformatie (zoals de plaats 
van herkomst, de bestemming en of het vak leeg of vol is). Een bericht moet 
wachten tot er een leeg vak aankomt. De locatie doet dan zijn bericht in het 
vak, waarbij hij de juiste besturingsinformatie instelt. Het vak met het bericht 
vervolgt dan zijn weg door het netwerk. Wanneer het in een bepaalde locatie 
aankomt, moet de besturingsinformatie worden geïnspecteerd om na te gaan 
of het vak een bericht voor deze locatie bevat. Is dat niet het geval, dan laat 
de locatie het vak en het bericht weer verder circuleren. Anders neemt de loca- 
tie het bericht weg en stelt hij de besturingsinformatie opnieuw in om aan te 
geven dat het vak leeg is. De locatie kan dan het vak gebruiken om zijn eigen 
bericht te verzenden óf het vak vrijgeven. Omdat een vak alleen berichten met 
een vaste lengte kan bevatten, moet een logisch bericht misschien in een aantal 
kleinere pakketjes opgebroken worden, waarvan elk dan in een apart vak ver- 
stuurd wordt. Deze methode is gevolgd in de Cambridge Digital Communi- 
cation Ring [Wilkes en Wheeler 1979]. 


13.3.4 Veiligheidszekerheid 


Naarmate computernetwerken aan populariteit winnen wordt er steeds meer ver- 
trouwelijke informatie verstuurd over kanalen waar berichten af geluisterd en on- 
derschept kunnen worden. Om een paar voorbeelden te noemen: bankrekenin- 
gen, medische gegevens en strafregisters worden nu als routinehandeling van de 
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ene naar de andere locatie gestuurd, in het algemeen in afzonderlijke netwerken 
voor speciale doeleinden. Met het oog op de veiligheidszekerheid van zulke ver- 
trouwelijke informatie moeten er mechanismen beschikbaar zijn die een gebrui- 
ker in staat stellen gegevens die over het netwerk worden verzonden te beveiligen. 

Codering is een veelgebruikte methode om informatie die over onbetrouw- 
bare lijnen wordt gestuurd te beveiligen. De gegevens die de informatie bevatten 
worden gecodeerd voordat deze worden verstuurd. Bij aankomst op de bestem- 
ming worden de gegevens gedecodeerd. Zelfs als een niet-geautoriseerd persoon 
toegang krijgt tot de gecodeerde informatie, zal deze waardeloos zijn tenzij het 
bericht gedecodeerd kan worden. Het belangrijkste is het ontwikkelen van co- 
deringsschema’s die onmogelijk (of erg moeilijk) gekraakt kunnen worden. 

Er zijn allerlei methoden om deze taak uit te voeren. De meest gebruikelijke 
methoden leveren een algemeen coderingsalgoritme C, een algemeen decodering- 
salgoritme D en een geheime sleutel (of sleutels) die voor elke toepassing moet 
worden gegeven. Laten Cx en Dx respectievelijk het coderings- en het decodering- 
salgoritme voorstellen voor een bepaalde toepassing met sleutel k. Dan moet het 
coderingsalgoritme voor elk bericht m voldoen aan de volgende eigenschappen: 


a. D(Ck(m)) = m. 

b. Zowel Cx als Dx kunnen efficiënt berekend worden. 

c. De veiligheidszekerheid van het systeem moet alleen afhangen van de geheim- 
houding van de sleutel en niet van de geheimhouding van de algoritmen C en 
D. 


Eén zo’n methode, de Data Encryption Standard (Standaard voor het Co- 
deren van Gegevens) werd onlangs aangenomen door het Amerikaanse National 
Bureau of Standards. Deze methode gaat mank aan het probleem van de sleutel- 
verdeling: voordat er communicatie kan plaatsvinden moeten de geheime sleutels 
veilig worden overgestuurd naar zowel de afzender als de ontvanger. Deze taak 
kan niet effectief in een communicatienetwerk worden volbracht. Een oplossing 
voor dit probleem is het gebruik van een coderingsschema met een openbare sleutel 
[Diffie en Hellman 1976]. Elke gebruiker heeft zowel een openbare sleutel als een 
privé-sleutel en twee gebruikers kunnen alleen met elkaar communiceren wan- 
neer zij elkaars openbare sleutel weten. 

Een algoritme dat op dit idee gebaseerd is werd enkele jaren geleden voor- 
gesteld door Rivest, Shamir en Adleman [1978]. Men gelooft dat dit algoritme 
bijna niet te kraken is. De openbare coderingssleutel is een paar (c, n); de prive- 
sleutel is een paar (d, n), waarin c, d en n positieve gehele getallen zijn. Elk bericht 
wordt voorgesteld als een geheel getal tussen 0 en n—1. (Een lang bericht wordt 
in een reeks kleinere berichten verdeeld, waarvan elk als een geheel getal kan 
worden voorgesteld.) De functies C en D zijn gedefinieerd als 


C(m) = m mod n = K. 
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D(K) = Ké mod n. 


Het belangrijkste probleem wordt gevormd door het kiezen van de code- 
rings- en decoderingssleutels. Het gehele getal n wordt berekend als het produkt 
van twee grote (100 of meer cijfers) willekeurig gekozen priemgetallen p en g, 
waarbij 


n =p X q. 


Het gehele getal d wordt gekozen als een groot, willekeurig gekozen geheel getal 
dat relatief priem is ten opzichte van (p—1)x(g—1). Dat wil zeggen, d voldoet 
aan 


Grootste Gemene Deler[d,(p—1) x (q—1)] = 1 


Tenslotte wordt het gehele getal c uit p, q en d berekend zo dat dit het omgekeerde 
is van d modulo (p—1) X (q—1). Dat wil zeggen, c voldoet aan 


c X d mod (p-I)X(q-1) = 1. 


We moeten er wel op letten dat, hoewel n publiekelijk bekend is, p en q dat niet 
zijn. Deze voorwaarde is te danken aan het bekende feit dat het heel moeilijk is 
om n te ontbinden. Daarom kunnen de gehele getallen c en d niet gemakkelijk 
geraden worden. 

We lichten deze methode toe aan de hand van een voorbeeld. Als p= Sen 
q = 7, dan is n = 35 en (p—1)X(q—1) = 24. Omdat 11 relatief priem is ten 
opzichte van 24, kunnen we d = 11 kiezen; en omdat 11 X 11 mod 24 = 121 
mod 24 = 1, isc = 11. Stel nu dat m = 3, dan geldt: 


K = m mod n = 3!! mod 35 12 


en 
K? mod n = 12"! mod 35 = 3 = m. 

Dus als we m coderen met gebruikmaking van c, kunnen we m decoderen met 

gebruikmaking van d. 

13.3.5 Ontwerpkwesties 

Bij het ontwerpen van een communicatienetwerk hebben we te maken met de 


daarmee samengaande complexiteit van het coördineren van asynchrone bewer- 
kingen die met elkaar communiceren in een in aanleg langzame en foutgevoelige 
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omgeving. Het ontwerpprobleem (en de daarmee verband houdende implementa- 
tie) zouden vereenvoudigd kunnen worden door het probleem in een aantal lagen 
te verdelen. In navolging van de Internationale Organisatie voor Standaardise- 
ring (International Standards Organization; ISO), kunnen we de lagen als volgt 
omschrijven: 


1. De fysieke laag is verantwoordelijk voor het behandelen van zowel de mecha- 
nische als de elektrische details van de fysieke transmissie van een bitstroom. 

2. De gegevensverbindingslaag is verantwoordelijk voor het behandelen van de 
pakketten, met inbegrip van de opsporing en het herstel van fouten die in de 
fysieke laag zijn opgetreden. 

3. De netwerklaag is verantwoordelijk voor de verbindingen en de routebepaling 
van de pakketten in het communicatienetwerk, inclusief het adresseren van 
uitgaande pakketten, het decoderen van het adres van inkomende pakketten 
en het onderhouden van de routebepalingsinformatie om op de juiste wijze te 
reageren op veranderingen in de belasting van de lijnen. 

4. De transportlaag is verantwoordelijk voor de toegang op laag niveau tot het 
netwerk en het overbrengen van berichten tussen de gebruikers, inclusief het 
verdelen van berichten over pakketten, het handhaven van de volgorde van de 
pakketten, de besturing van de stroom, en het genereren van fysieke adressen. 

5. De sessielaag is verantwoordelijk voor het implementeren van de proces-naar- 
proces-protocollen. 

6. De presentatielaag is verantwoordelijk voor het oplossen van verschillen in de 
formaten die voorkomen bij de verschillende locaties in het netwerk, met inbe- 
grip van tekenconversies en half duplex/full duplex (echoing). 

7. De toepassingslaag is verantwoordelijk voor het rechtstreeks in wisselwerking 
treden met de gebruikers. Deze laag heeft te maken met elektronische post, 
alsook met methoden voor gedistribueerde databases. 


13.4 Soorten systemen 


Fundamenteel zijn er twee soorten gedistribueerde systemen: het computernet- 
werk en het lokale netwerk (Engels: Local Area Network; LAN). Het belangrijkste 
verschil tussen deze beide is de manier waarop zij geografisch gespreid zijn. Com- 
puternetwerken zijn samengesteld uit een aantal autonome processoren die over 
een groot geografisch gebied (zoals de Verenigde Staten) verspreid staan, terwijl 
lokale netwerken uit processoren zijn opgebouwd die over kleine geografische 
gebieden, zoals een enkel gebouw of een aantal aan elkaar grenzende gebouwen, 
verspreid zijn. Deze verschillen brengen aanzienlijke variaties in de snelheid en 
betrouwbaarheid van het communicatienetwerk met zich mee en deze variaties 
weerspiegelen zich in het ontwerp van het besturingssysteem. 


13.4 Soorten systemen 


13.4.1 Computernetwerken 


Computernetwerken kwamen op aan het eind van de jaren ’60, voornamelijk als 
een academisch onderzoekproject om efficiënte communicatie tussen locaties te 
verzorgen, zodat tal van gebruikers gemakkelijk en economisch gemeenschappe- 
lijk gebruik zouden kunnen maken van de apparatuur en de programmatuur. Het 
eerste netwerk dat ontworpen en ontwikkeld werd was het Arpanet [McQuillan 
en Walden 1977]. Het werk aan het Arpanet begon in 1968. Van een experimen- 
teel netwerk met vier locaties groeide het uit tot een communicatiesysteem over 
de gehele Verenigde Staten dat uit ongeveer honderd computersystemen bestaat. 
Nog niet zo lang geleden hebben ook een aantal commerciéle netwerken zich op 
de markt aangediend. Het Telenet-systeem is beschikbaar op het vasteland van 
de Verenigde Staten, terwijl in Canada het Datapac-systeem beschikbaar is. Deze 
netwerken bieden hun gebruikers de mogelijkheid toegang te krijgen tot een groot 
aantal verschillende computersysteemfaciliteiten: apparatuur zowel als program- 
matuur. 

Daar de locaties in een computernetwerk fysiek over een groot geografisch 
gebied verspreid liggen, zijn de communicatieverbindingen per definitie betrekke- 
lijk langzaam en onbetrouwbaar. Typische voorbeelden van zulke verbindingen 
zijn telefoonlijnen, verbindingen met behulp van microgolven en satellietkanalen. 
Deze communicatieverbindingen worden door speciale communicatieprocessoren 
bestuurd (zie figuur 13.7), die verantwoordelijk zijn voor het definiéren van de 
aansluiting via welke de locaties over het netwerk met elkaar communiceren, 
alsook voor het overbrengen van informatie tussen de verschillende locaties. 

Laten we als specifiek voorbeeld het Arpanet nemen. Het systeem verschaft 
locaties die geografisch van elkaar gescheiden zijn, hosts (in het Nederlands ’gast- 
heren’) geheten, met elkaar te communiceren. De host-computers verschillen ge- 
woonlijk van elkaar in type, snelheid, woordlengte, besturingssysteem, enzovoort. 
ledere host-computer is met het netwerk verbonden via een lokale kleine compu- 
ter die een aansluitings-berichtenprocessor (Interface Message Processor of IMP) 
genoemd wordt. Het volledige netwerk wordt gevormd door de IMP’s, die alle 
nagenoeg identiek zijn, met elkaar te verbinden door middel van breedband-com- 
municatielijnen (50 kilobits per seconde), die door de telefoondienst worden gele- 
verd. Elke IMP is zo geprogrammeerd dat deze pakketten opslaat en naar de 
naburige IMP’s in het netwerk doorstuurt. Wanneer een host een bericht aflevert 
aan zijn lokale IMP, bevatten de eerste 32 bits van het bericht onder andere het 
adres binnen het netwerk van een bestemming-host. Het bericht wordt van IMP 
naar IMP door het netwerk doorgegeven tot het tenslotte op de bestemming-IMP 
aankomt. De bestemming-IMP geeft het bericht door aan de bestemming-host. 


13.4.2 Lokale netwerken 


Lokale netwerken (Local Area Networks; LAN’s) deden hun intrede in de begin- 
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Figuur 13.7 
Communicatieprocessoren in een computernetwerk 


jaren ’70 , als een vervanging voor grote mainframe computersystemen. Het was- 
duidelijk geworden dat het voor veel ondernemingen lonender was een aantal 
kleine computers te hebben waarbij elk zijn eigen toepassingen had, dan één 
groot systeem. Daar elke kleine computer een compleet stel randapparaten (zoals 
schijven en printers) nodig heeft en aangezien een zekere mate van gemeenschap- 
pelijk gebruik van gegevens ook wel waarschijnlijk is binnen één onderneming, 
was het een logische stap al deze kleine systemen met elkaar in een netwerk te 
verbinden. 


13.4 Soorten systemen 


Lokale netwerken worden gewoonlijk ontworpen voor het bestrijken van 
een zeer klein geografisch gebied (zoals een enkel gebouw, of een paar aan elkaar 
grenzende gebouwen) en ze worden gewoonlijk gebruikt in een kantooromgeving. 
Omdat alle locaties in zulke systemen dicht bij elkaar liggen, hebben de com- 
municatielijnen een grotere snelheid en minder storingen dan hun tegenpolen in 
computernetwerken. De meest voorkomende verbindingen zijn dubbele spiraal, 
basisband-coax-kabel, breedband-coax-kabel en glasvezelkabel. De meest voor- 
komende configuraties zijn stervormige netwerken, ringnetwerken en hoofdtrans- 
missielijnen met meervoudige toegang. 

Een typische LAN kan bestaan uit een aantal minicomputers, diverse ge- 
meenschappelijk gebruikte randapparaten (zoals laser-printers of magneetband- 
eenheden), werkstations en een of meer gespecialiseerde processoren (gateways) 
die toegang verschaffen tot andere netwerken (zie figuur 13.8). Gewoonlijk wordt 
van een Ethernet-opzet gebruik gemaakt om LAN’s te bouwen. Het communi- 
catiemedium is een coax-kabel met meervoudige toegang en met de methode voor 
het signaleren van botsingen die in paragraaf 13.3.3 beschreven werd. Berichten 
tussen de verschillende knooppunten in het netwerk worden als pakketten ver- 
zonden. Omdat er geen centrale besturingseenheid is, kunnen gemakkelijk nieuwe 
locaties aan het netwerk worden toegevoegd. 
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Figuur 13.8 
Lokaal netwerk (Local Area Network; LAN) 
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13.5 Bestandssystemen 


Er zijn twee kwesties van groot belang die de ontwerpcriteria in een gedistri- 
bueerd bestandssysteem beheersen: 


@ Transparantheid. Benadert een gebruiker alle bestanden in een systeem op de- 
zelfde wijze, ongeacht waar deze zich bevinden? 
@ Lokaliteit. Waar bevinden bestanden zich in het systeem? 


In de volgende paragrafen bespreken we deze vragen in verband met de drie 
meest voorkomende manieren waarop bestandssystemen in een gedistribueerde 
omgeving georganiseerd zijn. 


13.5.1 Arpanet FTP 


Iedere locatie onderhoudt zijn eigen bestandssysteem. Als een gebruiker in locatie 
A toegang wenst tot een bestand in locatie B, moet het bestand expliciet van de 
ene naar de andere locatie worden gekopieerd. 

Het Arpanet levert een mechanisme voor zo’n overdracht door middel van 
het programma voor het protocol voor het overbrengen van bestanden (File 
Transfer Protocol; FTP). Stel dat een gebruiker een niet-lokaal bestand Bı van 
locatie B wil kopiëren naar een lokaal bestand B2, en het lokale bestand B3 wil 
kopiëren naar een niet-lokaal bestand B4 in locatie B. De gebruiker moet eerst 
het FTP-programma aanroepen. Het programma verzoekt de gebruiker dan om 
de volgende informatie: 


a. De naam van de locatie waarvan of waarnaar de bestandsoverbrenging moet 
plaatsvinden (dat wil zeggen, locatie B). 

b. Toegangsinformatie (gebruikersnaam en wachtwoord) om te controleren of 
de gebruiker de juiste toegangsrechten in locatie B heeft. 


Is de gebruiker door deze controle heengekomen, dan kan hij het niet-lokale be- 
stand Bı vanuit B kopiëren door uit te voeren: 


haal B: naar B2. 
Het lokale bestand B4 wordt naar B3 gekopieerd door de uitvoering van: 
zend B; naar Ba. 
Bij deze methode is de plaats waar het bestand zich bevindt niet transparant voor 


de gebruiker. De gebruikers dienen precies te weten waar elk bestand is. Boven- 
dien worden bestanden niet echt gemeenschappelijk gebruikt, omdat de gebrui- 
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ker alleen maar een bestand van de ene naar de andere locatie kan kopiëren. Op 
deze manier kunnen er verschillende kopieën van hetzelfde bestand bestaan, wat 
ruimteverspilling tot gevolg heeft. Daar komt nog bij dat we, als deze kopieën 
gewijzigd worden, tot de ontdekking kunnen komen dat de verschillende kopieën 
niet consistent zijn. 


13.5.2 Gecentraliseerde aanpak 


Elke locatie onderhoudt zijn eigen bestandssysteem. Tot een bestand kunnen al- 
leen die gebruikers toegang krijgen die in die locatie verblijven. Alle gemeen- 
schappelijk gebruikte bestanden bevinden zich in één gecentraliseerde locatie, die 
een bestandsdienstverlener (Engels: file server) wordt genoemd. Als een gebruiker 
een niet-lokaal bestand opent, wordt het open-verzoek naar de bestandsdienstver- 
lener doorgesluisd. 

Bij deze opzet is de plaats waar een bestand zich bevindt transparant voor 
de gebruikers, die tot niet-lokale bestanden op dezelfde wijze toegang krijgen als 
tot lokale bestanden. Het besturingssysteem zet automatisch toegangsverzoeken 
tot gemeenschappelijke (niet-lokale) bestanden om in berichten naar de bestands- 
dienstverlener. Het belangrijkste probleem bij deze opzet is dat de bestands- 
dienstverlener een knelpunt kan worden. Iedere toegang tot een niet-lokaal be- 
stand kan een aanzienlijke overhead aan berichtenoverdracht met zich meebren- 
gen. 


13.5.3 Gedistribueerde aanpak 


Elke locatie onderhoudt zijn eigen bestandssysteem. In tegenstelling tot de gecen- 
traliseerde aanpak kan een lokaal bestand benaderd worden door een gebruiker 
die zich in een of andere locatie in het systeem bevindt. Er zijn twee manieren 
voor het behandelen van deze aanpak die elkaar aanvullen. Bij de eenvoudigste 
manier moet de gebruiker de locatie van elk te benaderen bestand weten. De 
locatie waar het bestand zich bevindt is niet transparant voor de gebruikers, die 
bij iedere toegangsaanroep de bestandslocatie moeten opgeven. Het is met deze 
opzet niet gemakkelijk om bestanden door het systeem heen en weer te laten 
gaan, omdat alle gebruikers op de hoogte gesteld moeten worden van de locatie 
waar het bestand zich nu bevindt. 

De andere manier maakt de plaats waar het bestand zich bevindt transpa- 
rant voor de gebruiker. De gebruiker hoeft niet te weten waar het bestand zich 
bevindt; tot niet-lokale bestanden wordt op dezelfde wijze toegang verkregen als 
tot lokale bestanden. Bij deze aanpak is het gemakkelijk om bestanden door het 
systeem te laten gaan. Het besturingssysteem moet tabellen onderhouden en algo- 
ritmen gebruiken om een bestand overal in het netwerk te kunnen vinden. 
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13.6 Wijze van computerverwerking 


Een gedistribueerd systeem geeft een gebruiker toegang tot de verschillende sys- 
teemfaciliteiten die in het systeem vóórkomen. Met systeemfaciliteiten bedoelen 
we zowel apparatuur (zoals printers) als programmatuur (zoals bestanden en pro- 
gramma’s). In deze paragraaf gaan we kort in op de verschillende manieren waar- 
op toegang tot gemeenschappelijk gebruikte systeemfaciliteiten wordt verkregen. 


13.6.1 Gegevensverplaatsing 


Wanneer een gebruiker in locatie A toegang tot gegevens (zoals een bestand) in 
locatie B wil krijgen, zijn er twee fundamentele methoden volgens welke het sys- 
teem de gegevens overbrengt. Bij de ene aanpak wordt het gehele bestand naar 
locatie A overgebracht. Vanaf dat moment is elke toegang tot het bestand lokaal. 
Wanneer de gebruiker geen toegang tot het bestand meer wenst, wordt een kopie 
ervan (als wijziging heeft plaatsgevonden) teruggestuurd naar locatie B. Natuur- 
lijk moet, ook als er een heel kleine wijziging in een groot bestand is gemaakt, 
de totale hoeveelheid gegevens worden overgebracht. 

De andere aanpak is alleen die gedeelten van het bestand naar locatie A 
over te brengen die op dat moment voor de onmiddellijke taak noodzakelijk zijn. 
Is een ander gedeelte later nodig, dan wordt dat op een ander moment overge- 
bracht. Wanneer de gebruiker niet langer toegang tot het bestand wenst, moet 
elk deel dat gewijzigd is naar locatie B teruggestuurd worden. (Let op de overeen- 
komst met pagineren op verzoek.) 

Het is duidelijk dat, als slechts een klein deel van een groot bestand be- 
naderd wordt, de tweede aanpak de voorkeur verdient. Als aanzienlijke gedeelten 
van het bestand worden benaderd is het efficiënter het gehele bestand te kopië- 
ren. 

We moeten erop wijzen dat het niet voldoende is de gegevens louter en 
alleen van de ene naar de andere locatie over te brengen. Het systeem moet de 
gegevens ook diverse malen vertalen als de twee betrokken locaties niet direct 
uitwisselbaar zijn (bijvoorbeeld als ze verschillende tekencode-representaties ge- 
bruiken of gehele getallen met een verschillend aantal bits voorstellen). 


13.6.2 Verwerkingsverplaatsing 


In sommige omstandigheden kan het efficiénter zijn om in plaats van de gegevens 
de verwerking naar een ander deel van het systeem over te brengen. Neem bij- 
voorbeeld een job die een groot aantal bestanden moet benaderen die zich in 
verschillende locaties bevinden, met het doel een overzicht van die bestanden te 
verkrijgen. Het zou efficiénter zijn de bestanden in de locaties waar deze zich 
bevinden te benaderen en dan de verlangde resultaten terug te sturen naar de 
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locatie die de verwerking op gang bracht. 

Zo’n verwerking kan op een aantal verschillende manieren worden uitge- 
voerd. Stel dat proces p toegang wil tot een bestand in locatie A. De toegang 
vindt plaats in locatie A en zou door een procedureaanroep op afstand op gang 
kunnen worden gebracht. Proces p roept een van tevoren bepaalde procedure in 
locatie A aan. De procedure wordt op de juiste wijze uitgevoerd en geeft dan de 
benodigde parameters terug aan p. 

Het is ook mogelijk dat proces p een bericht naar locatie A stuurt. Het 
besturingssysteem in locatie A roept een nieuw proces q in het leven, dat tot 
functie heeft de aangewezen taak uit te voeren. Wanneer proces q met de uitvoe- 
ring klaar is, stuurt het het benodigde resultaat naar p terug via het berichtensys- 
teem. Let erop dat volgens deze methode proces p parallel met proces q kan 
worden uitgevoerd en dat in feite verschillende processen in verschillende locaties 
parallel kunnen worden uitgevoerd. 

Men zou van beide methoden gebruik kunnen maken om toegang te krijgen 
tot diverse bestanden die zich in diverse locaties bevinden. De ene procedureaan- 
roep op afstand kan een andere procedureaanroep, of zelfs de overbrenging van 
berichten naar een andere locatie, tot gevolg hebben. Op soortgelijke wijze zou 
proces q, tijdens het verloop van zijn uitvoering, een bericht naar een andere 
locatie kunnen sturen, die op zijn beurt weer een ander proces in het leven roept. 
Dit proces kan dan ofwel een bericht naar g terugsturen ofwel de bovenstaande 
cyclus herhalen. 


13.6.3 Job-verplaatsing 


Wanneer een job in een bepaalde locatie in het systeem arriveert, kan het voor- 
delen hebben de gehele job, of gedeelten ervan, in andere locaties uit te voeren. 
Deze methode kan om diverse redenen worden gebruikt: 


@ In balans brengen van de belasting (Engels: load balancing). De jobs (of sub- 
jobs) kunnen over het systeem gedistribueerd worden om de werkbelasting 
gelijk te verdelen. 

@ Snellere verwerking. Als één job in een aantal subjobs kan worden verdeeld 
die in een aantal verschillende locaties parallel kunnen draaien, kan de turn- 
around-tijd van jobs omlaag worden gebracht. 

@ Voorkeur voor bepaalde apparatuur. De job kan zekere eigenschappen hebben 
waardoor hij geschikter is om op een of andere gespecialiseerde processor te 
worden uitgevoerd (zoals het inverteren van een matrix op een array-processor 
in plaats van op een microprocessor). 

@ Voorkeur voor bepaalde programmatuur. De job kan programmatuur vereisen 
die alleen in een bepaalde locatie beschikbaar is, terwijl óf de programmatuur 
niet kan worden verplaatst óf het goedkoper is de job te verplaatsen. 


48- Hoofdstuk 13 Gedistribueerde systemen 


Fundamenteel wordt er van twee elkaar aanvullende technieken gebruik gemaakt 
om jobs in een netwerk te verplaatsen. Het systeem kan trachten het feit dat de 
job verplaatst is voor de gebruiker te verbergen. Deze methode heeft het voordeel 
dat programmeurs in hun programma’s niet expliciet code hoeven aan te brengen 
om de verplaatsing te bewerkstelligen. Deze methode wordt gewoonlijk gebruikt 
voor het realiseren van het in balans brengen van de werkbelasting en voor snel- 
lere verwerking. 

De andere manier staat toe (of eist) dat de gebruiker expliciet specificeert 
hoe de job verplaatst moet worden. Deze methode wordt gewoonlijk gebruikt 
wanneer de job verplaatst moet worden om te voldoen aan een bepaalde voorkeur 
voor apparatuur of programmatuur. 


13.7 Volgordebepaling van gebeurtenissen 


In een gecentraliseerd of ’sterk-gekoppeld’ systeem is het altijd mogelijk de volg- 
orde waarin twee gebeurtenissen zijn opgetreden te bepalen, omdat er één geheu- 
gen is en één klok. In veel toepassingen is het van het grootste belang dat we in 
staat zijn de volgorde van gebeurtenissen te bepalen. In een schema voor het 
toewijzen van systeemfaciliteiten bijvoorbeeld, specificeren we dat een systeem- 
faciliteit alleen kan worden gebruikt nadat deze is toegewezen. In een gedistri- 
bueerd systeem is er echter geen gemeenschappelijk geheugen en geen gemeen- 
schappelijke klok. Daarom is het soms onmogelijk te zeggen welke van twee ge- 
beurtenissen het eerst heeft plaatsgevonden. De eerder-gebeurd-relatie is slechts 
een gedeeltelijke ordening van de gebeurtenissen in gedistribueerde systemen. 
Omdat het vermogen om een totale ordening te definiëren in veel toepassingen 
van essentieel belang is, geven we hieronder een gedistribueerd algoritme dat 
afkomstig is van Lamport [1978a], voor het uitbreiden van de eerder-gebeurd- 
relatie tot een consequente totale ordening van alle gebeurtenissen in het systeem. 


13.7.1 De eerder-gebeurd-relatie 


Omdat processen sequentieel zijn, zijn alle gebeurtenissen binnen één proces vol- 
ledig geordend. Ook kan, volgens de wet van de causaliteit, een bericht pas ont- 
vangen worden nadat het verzonden is. Daarom kunnen we de ’eerder-gebeurd’- 
relatie (die we aangeven door middel van het teken —) op een reeks gebeurtenis- 
sen als volgt definiëren (aangenomen dat het zenden zowel als het ontvangen van 
een bericht een gebeurtenis vormt): 


1. Als A en B gebeurtenissen binnen hetzelfde proces zijn en A vóór B werd 
uitgevoerd, dan geldt A — B. 


13.7 Volgordebepaling van gebeurtenissen 


2. Als A de gebeurtenis is van het verzenden van een bericht door het ene proces 
en B de gebeurtenis van het ontvangen van dat bericht is door een ander 
proces, dan geldt A — B. 

3. Als A > Ben B > C, dan geldt A > C. 


Aangezien een gebeurtenis niet vóór zichzelf kan plaatsvinden, stelt de — relatie 
een niet-omkeerbare gedeeltelijke ordening voor. 

Als tussen twee gebeurtenissen A en B niet de — relatie geldt (dat wil zeg- 
gen, A gebeurde niet vóór B en B gebeurde niet vóór A), dan zeggen we dat 
de twee gebeurtenissen parallel plaatsvonden. In dit geval kan geen van beide 
gebeurtenissen causaal op de andere van invloed zijn. Als echter A — B, dan is 
het mogelijk dat gebeurtenis A causaal van invloed is op gebeurtenis B. 

De definities van parallellisme en ’eerder-gebeurd’ kunnen het best worden 
geïllustreerd aan de hand van een ruimte-tijd-diagram, zoals in figuur 13.9. De 
horizontale richting stelt de ruimte (dat wil zeggen, verschillende processen) en 
de verticale richting de tijd voor. De verticale lijnen met de labels P, Q en R 
geven processen (of processoren) aan. De van labels voorziene punten stellen 
gebeurtenissen voor. Een golflijntje betekent een bericht dat van het ene naar het 
andere proces gezonden wordt. Aan de hand van dit diagram wordt duidelijk dat 
de gebeurtenissen A en B dan en slechts dan parallel plaatsvinden als er geen 
pad bestaat dat van A naar B of van B naar A loopt. 

Kijk bijvoorbeeld eens naar figuur 13.9. Sommige gebeurtenissen waarvoor 
de eerder-gebeurd-relatie geldt zijn: 


p: > q2 
ro > q4 
q3 > rı 
Pi > qa (omdat pi > q2 en q2 — qa). 


Figuur 13.9 
Relatieve tijd voor drie parallelle processen 
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Sommige parallelle gebeurtenissen zijn: 


qo en p2 
ro en q3 
ro en p3 


q3 en ps. 


We kunnen niet weten welke van twee parallelle gebeurtenissen, zoals go en pa, 
het eerst plaatsvond. Daar echter geen van beide gebeurtenissen op de andere 
van invloed kan zijn (op geen enkele manier kan de een te weten komen of de 
andere al gebeurd is), is het niet van belang welke van beide het eerst heeft plaats- 
gevonden. Het is alleen belangrijk dat processen, waarvoor de volgorde van twee 
parallelle gebeurtenissen er wel toe doet, een afspraak maken over een of andere 
volgorde. 


13.7.2 Implementatie 


Om te kunnen bepalen of een gebeurtenis A vóór een gebeurtenis B heeft plaats- 
gevonden, moeten we een gemeenschappelijke klok óf een stel perfect gesynchro- 
niseerde klokken hebben. Omdat in een gedistribueerd systeem geen van beide 
beschikbaar is, moeten we de eerder-gebeurd-relatie zonder het gebruik van fysie- 
ke klokken definiëren. 

Met elke systeemgebeurtenis verbinden we een tijdregistratie. Dan kunnen 
we de eis voor globale ordening definiëren: voor elk paar gebeurtenissen geldt dat 
als A — B, dan is de geregistreerde tijd van A kleiner dan de geregistreerde tijd 
van B. (Let wel dat het omgekeerde niet waar hoeft te zijn.) 

Hoe schrijven we de eis van globale ordening in een gedistribueerd systeem 
dwingend voor? We definiëren binnen elk proces p; een logische klok LKi. De 
logische klok kan worden geïmplementeerd als een eenvoudig telregister dat tus- 
sen elk tweetal opeenvolgende gebeurtenissen, die binnen een proces plaatsvin- 
den, wordt opgehoogd. Omdat de waarde van de logische klok monotoon toe- 
neemt, kent deze aan iedere gebeurtenis een uniek getal toe, zó dat als in proces 
pi een gebeurtenis A optrad vóór gebeurtenis B, geldt: LK(A) < LK(B). De tijd 
die voor een gebeurtenis geregistreerd wordt, is de waarde van de logische klok 
voor die gebeurtenis. Het zal duidelijk zijn dat deze methode de garantie geeft 
dat voor elk tweetal gebeurtenissen binnen hetzelfde proces aan de eis van globale 
ordening is voldaan. 

Helaas geeft deze methode niet de garantie dat voor verschillende processen 
aan de eis van globale ordening voldaan is. Om dit probleem toe te lichten nemen 
we eens aan we dat twee processen pi en p2 met elkaar communiceren. Stel dat 
pı een bericht naar p2 zendt (gebeurtenis A), waarbij LKi(A) = 200, en proces p2 
het bericht ontvangt (gebeurtenis B), waarbij LK2(B) = 195 (omdat de processor 
voor p2 langzamer is dan die voor pı en zijn logische klok dus ook langzamer 
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tikt). Deze situatie is in tegenspraak met de eis, omdat A — B terwijl de geregi- 
streerde tijd van A groter is dan die voor B. 

Om deze moeilijkheid op te lossen stellen we de eis dat een proces zijn 
logische klok vooruit zet, wanneer het een bericht ontvangt waarvan de geregi- 
streerde tijd groter is dan de huidige waarde van zijn logische klok. In het bijzon- 
der moet proces p;, wanneer dat een bericht ontvangt (gebeurtenis B) waarvan de 
geregistreerde tijd ¢ bedraagt en waarvoor LK(B) < t, zijn klok zoveel vooruit 
zetten dat LK(B) = t+1. Zo zal in het bovenstaande voorbeeld proces p2, wan- 
neer het het bericht van proces pı ontvangt, zijn logische klok zoveel vooruit 
zetten dat LKx(B) = 201. 

Tenslotte moeten we, om een totale ordening te realiseren, er nog slechts 
op letten dat met onze opzet van tijdregistratie, twee gebeurtenissen parallel zijn 
als de geregistreerde tijden van deze gebeurtenissen hetzelfde zijn. In dit geval 
kunnen we van de identiteit van het proces gebruik maken om uit deze impasse 
te komen en een totale ordening tot stand te brengen. 


13.8 Synchronisatie 


Om synchronisatieproblemen in gedistribueerde systemen op te lossen moeten 
we voor een mechanisme zorgen dat ons in staat stelt gedistribueerde semaforen 
te implementeren. Om de bespreking eenvoudig te houden richten we onze aan- 
dacht uitsluitend op het probleem van de implementatie van een binaire semafoor 
die de beginwaarde 1 krijgt. Dit staat gelijk aan het oplossen van het probleem 
van de wederzijdse uitsluiting. We hebben al aangetoond dat een semafoor kan 
worden geïmplementeerd als wederzijdse uitsluiting wordt geleverd binnen het 
raam van een gecentraliseerd systeem; daarom zijn we hier alleen geïnteresseerd 
in een gedistribueerde omgeving waarin n processen, die zich elk in een verschil- 
lende processor bevinden, een beroep willen doen op wederzijdse uitsluiting. Om 
de bespreking verder te vereenvoudigen nemen we aan dat de processen unieke 
nummers van | tot n hebben gekregen en dat er een l-l-relatie bestaat tussen 
processen en processoren (dat wil zeggen, elk proces heeft zijn eigen processor). 


13.8.1 Gecentraliseerde aanpak 


In een gecentraliseerde aanpak om te komen tot wederzijdse uitsluiting wordt 
één van de processen in het systeem uitgekozen om het binnengaan in de kritieke 
sectie te coördineren. Elk proces dat wederzijdse uitsluiting wil oproepen, stuurt 
een verzoek-bericht naar de coördinator. Wanneer het proces een antwoord-bericht 
van de coördinator ontvangt, kan het verder gaan en zijn kritieke sectie binnen- 
gaan. Nadat het proces zijn kritieke sectie verlaten heeft zendt het een vrijgave- 
bericht naar de coördinator en gaat het verder met zijn uitvoering. 

Bij het ontvangen van een verzoek-bericht controleert de coördinator of er 
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een ander proces in zijn kritieke sectie is. Is dat niet het geval, dan stuurt de 
coördinator onmiddellijk een antwoord-bericht terug. Anders wordt het verzoek 
in een wachtrij gezet. Wanneer de coördinator een vrijgave-bericht ontvangt, ver- 
wijdert het één van de verzoek-berichten uit de wachtrij (volgens een of ander 
algoritme voor werkindeling) en stuurt hij een antwoord-bericht naar het proces 
dat het verzoek deed. 

Het is duidelijk dat dit algoritme wederzijdse uitsluiting garandeert. Boven- 
dien kan er, als het werkindelingsbeleid eerlijk is (zoals WEKEM-werkindeling), 
geen verhongering optreden. Deze opzet vereist drie berichten per binnenkomst 
in een kritieke sectie: een verzoek, een antwoord en een vrijgave. 

Als het coördinator-proces door een storing uitvalt, moet een nieuw proces 
zijn plaats innemen. In paragraaf 13.10 verderop bespreken we de vraag hoe zo’n 
storing wordt gesignaleerd, alsook verschillende algoritmen voor het kiezen van 
een unieke nieuwe coördinator. Is eenmaal een nieuwe coördinator gekozen, dan 
moet het alle processen in het systeem polsen om zijn verzoek-wachtrij te recon- 
strueren. Nadat de wachtrij gereconstrueerd is kan de verwerking hervat worden. 


13.8.2 Volledig gedistribueerde aanpak 


Als we het nemen van beslissingen over het gehele systeem willen distribueren, 
is de oplossing veel gecompliceerder. De eerste oplossing hiervoor werd voorge- 
steld door Lamport [1978a], die gebruik maakte van een methode voor het or- 
denen van gebeurtenissen (paragraaf 13.7) om alle verzoeken voor kritieke secties 
volledig te ordenen, waarbij de processen bediend worden in WEKEM-volgorde. 
Lamport’s methode vereist 3 X (n—1) berichten per binnenkomst in een kritieke 
sectie. Daarna stelden Ricart en Agrawala [1981] een gedistribueerd algoritme 
voor (ook gebaseerd op de methode voor het ordenen van gebeurtenissen van 
Lamport) die slechts 2 X (n—1) berichten vereist. We laten nu hun algoritme 
zien. 

Wanneer een proces p zijn kritieke sectie wil binnengaan, maakt het een 
nieuwe tijdregistratie, TR, en stuurt het bericht verzoek(p,TR) naar alle andere 
processen in het systeem (met inbegrip van zichzelf). Na ontvangst van een ver- 
zoek-bericht kan een proces onmiddellijk antwoorden (dat wil zeggen, een ant- 
woord-bericht naar p terugsturen), of het kan het sturen van een antwoord-bericht 
uitstellen (bijvoorbeeld omdat het al in zijn kritieke sectie is). Een proces dat een 
antwoord-bericht van alle andere processen in het systeem ontvangen heeft, kan 
zijn kritieke sectie binnengaan. Na het verlaten van zijn kritieke sectie stuurt 
het proces antwoord-berichten op alle nog niet beantwoorde verzoeken die het 
ontvangen heeft. 

De beslissing of proces p onmiddellijk op een bericht verzoek(q,TR) ant- 
woordt of dit uitstelt hangt van drie factoren af: 


13.8 Synchronisatie 


a. Als proces p zich in zijn kritieke sectie bevindt, stelt het zijn antwoord aan q 
uit. 

b. Als proces p zijn kritieke sectie niet wil binnengaan, wordt onmiddellijk een 
antwoord naar g gezonden. 

c. Als proces p zijn kritieke sectie wel wil binnengaan maar nog niet binnen- 
gegaan is, vergelijkt het de tijdregistratie, zeg TR, voor zijn eigen verzoek 
met de tijdregistratie TR, van het binnenkomende verzoek van proces g. Als 
TR, kleiner is dan TR), wordt onmiddellijk een antwoord naar q uitgezonden 
(q kwam het eerst met zijn verzoek). Anders wordt het antwoord uitgesteld. 


Ricart en Agrawala [1981] hebben aangetoond dat dit algoritme het volgen- 
de wenselijke gedrag vertoont: 


Wederzijdse uitsluiting wordt verkregen. 

Het geheel is impasse-vrij. 

c. Het geheel is vrij van verhongering, omdat binnenkomst in de kritieke sectie 
wordt ingedeeld volgens de ordening naar tijdregistratie. Het ordenen naar 
tijdregistratie verzekert dat processen worden bediend in WEKEM-volgorde. 

d. Het aantal vereiste berichten is 2 X (n—1). Dit is het minimumaantal vereiste 

berichten per binnenkomst in de kritieke sectie wanneer processen onafhan- 

kelijk van elkaar en parallel optreden. 


Be > 


Om te illustreren hoe het algoritme werkt nemen we een systeem dat bestaat 
uit proces 1, proces 2 en proces 3. Stel dat proces 1 en proces 3 hun kritieke secties 
willen binnengaan. Proces 1 stuurt dan een verzoek (proces 1, tijdregistratie 10) 
naar de processen 2 en 3, terwijl proces 3 een verzoek (proces 3, tijdregistratie 4) 
naar de processen 1 en 2 stuurt. De tijdregistraties 4 en 10 werden verkregen uit 
de logische klokken die in paragraaf 13.7 zijn beschreven. Wanneer proces 2 deze 
verzoek-berichten ontvangt, antwoordt het onmiddellijk. Wanneer proces 1 het 
verzoek-bericht van proces 3 ontvangt, antwoordt het onmiddellijk, omdat de tijd- 
registratie (10) op zijn eigen verzoek groter is dan de tijdregistratie (4) voor proces 
3. Wanneer proces 3 het verzoek van proces 1 ontvangt, stelt het zijn antwoord 
uit, omdat de tijdregistratie (4) op zijn verzoek-bericht kleiner is dan de tijdregi- 
stratie (10) voor het bericht van proces 1. Na het ontvangen van de antwoorden 
van zowel proces 1 als proces 2, kan proces 3 zijn kritieke sectie binnengaan. Na 
het verlaten van zijn kritieke sectie stuurt proces 3 een antwoord naar proces 1, 
dat dan zijn kritieke sectie kan binnengaan. 

We moeten erop letten dat deze opzet de deelname van alle processen in 
het systeem vereist. Deze aanpak heeft twee ongewenste gevolgen: 


1. Het proces moet de identiteit kennen van alle andere processen in het systeem. 
Wanneer een nieuw proces bij de groep komt van processen die aan het algo- 
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ritme voor wederzijdse uitsluiting deelnemen, moeten de volgende acties wor- 

den ondernomen: 

a. Het proces moet de namen van alle andere processen in de groep ontvan- 
gen. 

b. De naam van het nieuwe proces moet aan alle andere processen in de groep 
worden medegedeeld. 

Deze taak is niet zo triviaal als het lijkt, omdat er een aantal verzoek- en ant- 

woord-berichten door het systeem kan circuleren wanneer het nieuwe proces 

bij de groep komt. Voor meer details verwijzen we de lezer die hierin belang 

stelt naar het artikel van Ricart en Agrawala [1981]. 

2. Als een proces door storing uitvalt, stort de gehele methode in elkaar. Deze 
moeilijkheid kan worden opgelost door voortdurend de toestand van alle 
processen in het systeem in de gaten te houden. Als één ervan uitvalt, moeten 
alle andere processen daarvan op de hoogte worden gesteld, zodat zij geen 
verzoek-berichten naar het uitgevallen proces meer sturen. Wanneer een proces 
weer op gang komt, moet het de procedure doorlopen die het proces in staat 
stelt zich weer bij de groep te voegen. 


13.8.3 Het doorgeven van een merkteken (token passing) 


Een andere methode om wederzijdse uitsluiting te verschaffen is dat we langs de 
processen van een systeem een merkteken laten circuleren. Een merkteken is een 
speciaal soort bericht dat in het systeem rondgestuurd wordt. Het bezit van het 
merkteken geeft zijn bezitter het recht de kritieke sectie binnen te gaan. Omdat 
er maar één merkteken in het systeem is, kan er slechts één proces tegelijk in zijn 
kritieke sectie zijn. 


Systemen met een ringstructuur 
We nemen aan dat de processen in het systeem logisch zijn georganiseerd in een 
ringstructuur (zie figuur 13.5). Het fysieke communicatienetwerk hoeft geen ring 
te zijn. Zolang de processen met elkaar verbonden zijn, is het mogelijk een logi- 
sche ring te implementeren. Voor het implementeren van wederzijdse uitsluiting 
wordt het merkteken langs de ring doorgegeven. Wanneer een proces het merk- 
teken ontvangt, mag het zijn kritieke sectie binnengaan, waarbij het het merk- 
teken houdt. Nadat het proces zijn kritieke sectie verlaten heeft, wordt het merk- 
teken weer doorgegeven. Als het proces dat het merkteken ontvangt zijn kritieke 
sectie niet wil binnengaan, geeft het het merkteken door aan zijn buurman. 
Het is wel duidelijk dat er slechts één proces tegelijk in zijn kritieke sectie 
kan zijn, omdat er slechts één merkteken is. Bovendien is verhongering uitgeslo- 
ten als de ring alleen eenrichtingsverkeer kent. Het aantal berichten nodig om 
wederzijdse uitsluiting te implementeren kan verschillen van één bericht per bin- 
nenkomst, in het geval van een hoge mate van wedijver (dat wil zeggen, ieder 
proces wil zijn kritieke sectie binnengaan), tot een oneindig aantal berichten, in 
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het geval van geringe wedijver (dat wil zeggen, niemand wil zijn kritieke sectie 
binnengaan). 

We moeten op twee soorten storingen letten. Ten eerste wordt, als het merk- 
teken zoekraakt, een verkiezing gehouden en genereert het verkozen proces dan 
een nieuw merkteken. Ten tweede moet, als een proces uitvalt, een nieuwe logi- 
sche ring worden gevormd. Er zijn een aantal verschillende algoritmen voor het 
verkiezen en het opnieuw opbouwen van een logische ring. In paragraaf 13.12 
zullen we een verzkiezingsalgoritme geven. We laten het ontwikkelen van een 
algoritme voor het opnieuw opbouwen van de ring ter oefening over aan de lezer. 


Systemen zonder ringstructuur 

In tegenstelling tot het systeem met ringstructuur, kan in systemen zonder ring- 
Structuur een proces dat het merkteken bezit dit aan elk willekeurig proces in het 
systeem sturen. Bovendien hoeft het merkteken niet doorgegeven te worden als 
geen enkel proces zijn kritieke sectie wil binnengaan. 

Het algoritme dat we hieronder geven en dat afkomstig is van Chandy 
[1982], garandeert dat elk proces dat het verzoek doet zijn kritieke sectie binnen 
te mogen gaan het merkteken binnen een eindige tijd gerekend vanaf het tijdstip 
van het verzoek zal ontvangen. Er zijn n processen in het systeem met de indices 
l tot en met n. Met het merkteken is een vector T = (Ti, Tə, … Tn) verbonden, 
waarin 7; het aantal malen aangeeft dat proces p; zijn kritieke sectie is binnen- 
gegaan. 

Wanneer een proces p; zijn kritieke sectie voor de mide keer wil binnengaan, 
stuurt het het bericht verzoek(p;, mj) naar alle andere processen in het systeem. 
Dan wacht het totdat het het merkteken ontvangt. Op dat tijdstip maakt het 7; 
in de merkteken-vector T gelijk aan m; en gaat het zijn kritieke sectie in. Na het 
verlaten van de kritieke sectie inspecteert proces p; de wachtrij van de binnen- 
gekomen verzoeken. Als de wachtrij leeg is, vervolgt het zijn normale uitvoering 
tot het een verzoek-bericht ontvangt van een ander proces. Zodra de wachtrij niet 
meer leeg is, verwijdert proces p; in beide gevallen het eerste verzoek, zeg (pj, mj), 
uit de wachtrij (die in FIFO-volgorde wordt onderhouden). Als m > Tj, stuurt 
p; het merkteken naar p;. Anders gooit het dit verzoek weg (het is een oud verzoek 
waaraan allang voldaan is), verwijdert het volgende verzoek uit de wachtrij en 
handelt als boven. Dit gaat zo door tot de wachtrij leeg is óf het merkteken naar 
een ander proces gestuurd wordt. 


13.9 Behandeling van impasses 


De algoritmen voor het voorkómen, vermijden en opsporen van impasses die we 
in hoofdstuk 8 hebben behandeld, kunnen ook in een gedistribueerd systeem 
worden gebruikt, mits ze op de juiste wijze worden aangepast. De techniek ter 
voorkoming van impasses door systeemfaciliteiten te ordenen kan bijvoorbeeld 
worden gebruikt door gewoon een globale ordening van systeemgebeurtenissen 
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te definiëren. Dat wil zeggen, alle systeemfaciliteiten in het gehele systeem krijgen 
een uniek getal, en een proces kan een systeemfaciliteit (in een willekeurige 
processor) met uniek getal i alleen verkrijgen als het geen systeemfaciliteit bezet 
houdt met een uniek getal dat kleiner dan of gelijk aan i is. Evenzo kan het 
bankiersalgoritme in een gedistribueerd systeem worden gebruikt door een van 
de processen in het systeem (de bankier) te bestempelen als het proces dat de 
informatie onderhoudt die nodig is om het bankiersalgoritme uit te voeren. Elk 
verzoek voor een systeemfaciliteit moet zo via de bankier gebeuren. 

Deze twee methoden kunnen in een gedistribueerde omgeving worden ge- 
bruikt om het impasseprobleem te behandelen. De eerste methode is eenvoudig 
te implementeren en vereist weinig overhead. De tweede methode kan ook een- 
voudig worden geïmplementeerd, maar kan teveel overhead met zich meebren- 
gen. De bankier kan een knelpunt gaan vormen, aangezien het aantal berichten 
van en naar de bankier nogal groot kan worden. Op deze manier lijkt het gebruik 
van het bankiersalgoritme in een gedistribueerd systeem niet praktisch. 

In deze paragraaf geven we twee mogelijke methoden, die vandaag de dag 
het meest worden gebruikt, voor het behandelen van het impasseprobleem in een 
gedistribueerd systeem. De eerste methode is gebaseerd op het voorkómen van 
impasses, terwijl de tweede gebaseerd is op het opsporen van impasses. Om de 
zaken simpel te houden beschouwen we alleen het geval dat elk type systeemfaci- 
liteit uit één exemplaar bestaat. 


13.9.1 De methode van ordening volgens tijdregistratie 


Voor het voorkómen van impasses willen we het systeem zó ontwerpen dat ten 
minste één van de vier noodzakelijke condities niet geldt. De aanpak die we zul- 
len bespreken voorkomt dat de conditie van het wachten-in-een-kring geldt, door 
zo nodig systeemfaciliteiten voortijdig te ontnemen. Om het voortijdige onder- 
breken te kunnen besturen kennen we aan elk proces een uniek prioriteitsgetal 
toe. Deze getallen worden gebruikt om te beslissen of een proces pi op een proces 
p; moet wachten. We zouden bijvoorbeeld p; op p; kunnen laten wachten als pi 
een hogere prioriteit heeft dan pj; anders wordt p; ‘teruggedraaid’ (teruggezet op 
het laatste controlepunt van waaruit het proces opnieuw kan worden gestart; 
Engels: ’rolled back’). Deze methode voorkomt impasses, omdat voor elke pijl 
(pi‚p‚) in de wacht-graaf geldt dat p; een hogere prioriteit heeft dan pj. Op deze 
wijze kan er geen lus optreden. 

Eén moeilijkheid met deze methode is de mogelijkheid van verhongering. 
Sommige processen met een erg lage prioriteit zouden altijd teruggedraaid kun- 
nen worden. Om deze moeilijkheid uit de weg te gaan hebben Rosenkrantz et al. 
[1978] voorgesteld tijdregistraties als prioriteiten te gebruiken. Aan elk proces in 
het systeem wordt een uniek getal toegekend wanneer het in het leven wordt 
geroepen. Men heeft twee elkaar aanvullende methoden ter voorkoming van im- 
passes voorgesteld. 
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@ De wacht-sterf-methode is gebaseerd op een techniek waarbij niet voortijdig 
wordt ontnomen. Wanneer proces p; om een systeemfaciliteit verzoekt die op 
dat ogenblik in het bezit is van p;, mag p; alleen wachten als het een kleinere 
tijdregistratie heeft dan p; (dat wil zeggen dat p; ouder is dan p;). Anders wordt 
pi teruggedraaid (sterft pi). Stel bijvoorbeeld dat de processen pi, p2 en p3 res- 
pectievelijk de tijdregistraties 5, 10 en 15 hebben. Als pı om een systeemfaci- 
liteit verzoekt die in het bezit is van p2 moet pı wachten. Als ps om een systeem- 
faciliteit verzoekt die in het bezit is van p2 wordt ps teruggedraaid. 

@ De verwond-wacht-methode is gebaseerd op een techniek waarbij wel voor- 
tijdig wordt ontnomen; deze methode is een tegenpool van het wacht-sterf- 
systeem. Wanneer proces p; om een systeemfaciliteit verzoekt die momenteel 
in het bezit is van pj, mag p; alleen wachten als het een grotere tijdregistratie 
heeft dan p; (dat wil zeggen, p; is jonger dan p;). Anders wordt p; teruggedraaid 
(p; wordt verwond door pi). We keren terug naar ons vorige voorbeeld, met de 
processen pi, p2 en p3. Als nu pi om een systeemfaciliteit verzoekt die in het 
bezit is van p2, wordt de systeemfaciliteit voortijdig aan p2 ontnomen en wordt 
p2 teruggedraaid. Als p om een systeemfaciliteit verzoekt die in het bezit is 
van p2 moet p3 wachten. 


Beide methoden kunnen verhongering vermijden, mits een proces, wanneer 
het teruggedraaid wordt, geen nieuwe tijdregistratie krijgt. Daar tijdregistraties 
altijd opklimmen in waarde, zal een proces dat teruggedraaid wordt uiteindelijk 
de kleinste tijdregistratie hebben. Op deze manier zal het dan niet weer terugge- 
draaid worden. Er zijn echter aanzienlijke verschillen in de manier waarop de 
twee methoden werken. 


@ In de wacht-sterf-methode moet een ouder proces wachten tot een jonger pro- 
ces zijn systeemfaciliteit vrijgeeft. Dus hoe ouder het proces wordt, hoe langer 
het zal moeten wachten. In tegenstelling daarmee zal bij de verwond-wacht- 
methode een ouder proces nooit op een jonger proces hoeven te wachten. 

@ In de wacht-sterf-methode kan een proces p; dat sterft en teruggedraaid wordt 
omdat het om een systeemfacilteit verzocht die in het bezit is van proces pj, 
dezelfde reeks verzoeken opnieuw doen wanneer het opnieuw gestart wordt. 
Als het systeemelement nog steeds in het bezit is van p; zal p; opnieuw sterven. 
Zo kan p; verschillende malen sterven voordat het de vereiste systeemfaciliteit 
verkrijgt. Vergelijk deze reeks gebeurtenissen nu eens met wat er gebeurt bij 
de verwond-wacht-methode. Proces p; wordt verwond en teruggedraaid omdat 
het in het bezit van een systeemfaciliteit was waar p; om verzocht. Wanneer Pi 
weer gestart wordt en om de systeemfacilteit verzoekt die nu in het bezit van 
P; is moet p; wachten. Er wordt dus bij de verwond-wacht-methode minder vaak 
een proces teruggedraaid. 


Het grote probleem met deze twee methoden is dat er wel eens onnodig een 
proces kan worden teruggedraaid. 
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13.9.2 Het opsporen van impasses 


Het algoritme ter voorkoming van impasses kan systeemfaciliteiten voortijdig 
ontnemen, zelfs als er geen impasse is opgetreden. Om onnodig voortijdig ontne- 
men te voorkómen kunnen we een algoritme voor het opsporen van impasses 
gebruiken. We construeren een wacht-graaf die de toewijzingstoestand van sys- 
teemfaciliteiten beschrijft. Omdat we uitgaan van slechts één exemplaar van elk 
type systeemfaciliteit, betekent een lus in de wacht-graaf een impasse. 

Het belangrijkste probleem in een gedistribueerd systeem wordt gevormd 
door de beslissing hoe de wacht-graaf moet worden onderhouden. We onderzoe- 
ken dit probleem wat nader door verschillende technieken te beschrijven die in 
gebruik zijn om deze kwestie te lijf te gaan. Deze technieken vereisen dat iedere 
locatie een lokale wacht-graaf bijhoudt. De knooppunten van de graaf correspon- 
deren met alle processen (lokale en niet-lokale) die momenteel een systeemfaci- 
liteit die lokaal is met betrekking tot die locatie in bezit hebben of daarom hebben 
verzocht. In figuur 13.10 hebben we bijvoorbeeld een systeem dat uit twee lo- 
caties bestaat, waarbij elke locatie zijn lokale wacht-graaf onderhoudt. Let erop 
dat de processen pz en p3 in beide grafen voorkomen, wat inhoudt dat de proces- 
sen in beide locaties om systeemfacilteiten hebben verzocht. 

Deze lokale wacht-grafen worden op de gebruikelijke wijze voor lokale 
processen en systeemfaciliteiten geconstrueerd. Wanneer een proces p in lokatie 
A een systeemfaciliteit nodig heeft die in het bezit is van proces q in locatie B, 
wordt er een verzoekbericht van p naar q gestuurd. De pijl (p,q) wordt dan in de 
lokale wacht-graaf van locatie B aangebracht. 

Het zal duidelijk zijn dat, als een lokale wacht-graaf een lus vertoont, er 
een impasse is opgetreden. Aan de andere kant betekent het feit dat er in elk van 
de lokale wacht-grafen geen lussen voorkomen niet dat er geen impasses zijn. Om 
dit probleem toe te lichten gaan we eens kijken naar het systeem dat in figuur 
13.10 is afgebeeld. Geen enkele wacht-graaf bevat lussen, maar toch is er sprake 
van een impasse in het systeem. Om te bewijzen dat er geen impasse is opgetre- 
den, moeten we laten zien dat de vereniging van alle lokale grafen geen lus bevat. 


ee © 


Locatie A Locatie B 


Figuur 13.10 
Lokale wacht-grafen 
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De graaf (weergegeven in figuur 13.11) die verkregen is door de vereniging te 
nemen van de twee wacht-grafen uit figuur 13.10, bevat inderdaad een lus. Dit 
betekent dat het systeem in een impassetoestand verkeert. 

Er zijn een aantal verschillende methoden om de wacht-graaf in een gedis- 
tribueerd systeem te construeren. Diverse methoden waarvan men vaak gebruik 
maakt worden hierna beschreven. 


Gecentraliseerde aanpak 

In de gecentraliseerde aanpak wordt een globale wacht-graaf geconstrueerd als 
de vereniging van alle lokale wacht-grafen. Deze globale wacht-graaf wordt in 
één proces onderhouden: de coördinator voor het opsporen van impasses. Omdat 
er in het systeem een communicatievertraging is, moeten we onderscheid maken 
tussen twee soorten wacht-grafen. De echte wacht-graaf beschrijft de werkelijke, 
maar onbekende, toestand van het systeem op elk moment, zoals deze door een 
alwetende waarnemer zou worden gezien. De geconstrueerde graaf is een benade- 
ring die door de coördinator wordt gemaakt tijdens de uitvoering van zijn algorit- 
me. Blijkbaar moet de geconstrueerde graaf zó worden gemaakt dat, telkens wan- 
neer het opsporingsalgoritme wordt aangeroepen, de gerapporteerde resultaten 
correct zijn: als er een impasse bestaat moet deze correct gemeld worden, en als 
het systeem een impasse meldt moet het zich inderdaad in een impassesituatie 
bevinden. Zoals we hieronder laten zien is het niet moeilijk zulke correcte algorit- 
men te construeren. 

De wacht-graaf kan op verschillende momenten worden geconstrueerd: 


1. Telkens wanneer er een nieuwe pijl in een van de lokale wacht-grafen wordt 
toegevoegd of daaruit wordt verwijderd. 

2. Periodiek, wanneer er een aantal wijzigingen in een wacht-graaf heeft plaats- 
gevonden. 

3. Telkens wanneer de coördinator het algoritme voor het opsporen van lussen 
moet aanroepen. 


Laten we, om dit toe te lichten, de eerste mogelijkheid eens bekijken. Tel- 
kens wanneer proces A een pijl in zijn lokale graaf toevoegt of daaruit verwijdert, 


Figuur 13.11 


Globale wacht-graaf voor figuur 13.10 
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moet het ook een bericht naar de coördinator sturen om hem deze wijziging mee 
te delen. Na ontvangst van zo’n bericht werkt de coördinator zijn globale graaf 
bij. De tweede mogelijkheid is dat proces A periodiek een aantal van zulke veran- 
deringen in één bericht stuurt. In ons voorgaande voorbeeld houdt de coördinator 
de wacht-graaf bij zoals afgebeeld in figuur 13.11. Wanneer locatie B de pijl 
(p3,p4) aan zijn lokale wacht-graaf toevoegt, zendt B ook een bericht naar de 
coördinator. Op dezelfde wijze wordt, wanneer locatie B de pijl (ps,pi) weghaalt, 
omdat pi een systeemfaciliteit heeft vrijgegeven waarom door ps werd verzocht, 
een bericht van die strekking naar de coördinator gestuurd. 

Wanneer het algoritme voor het opsporen van impasses wordt aangeroepen, 
doorzoekt de coördinator zijn globale graaf. De coördinator moet alle locaties 
meedelen dat een bepaald proces als slachtoffer is geselecteerd. De locaties 
draaien op hun beurt het slachtoffer-proces terug. 

We merken op dat bij deze methode onnodig terugdraaien kan plaatsvin- 
den, als gevolg van twee situaties: 


@ Er kunnen valse lussen in de globale wacht-graaf voorkomen. Om dit punt toe 
te lichten bekijken we de momentopname van het systeem zoals deze is afge- 
beeld in figuur 13.12. Stel dat p2 de systeemfaciliteit die het in bezit heeft in 
locatie A vrijgeeft. Dit heeft tot gevolg dat de pijl (p1,p2) in A verwijderd wordt. 
Proces p2 verzoekt dan om een systeemfaciliteit die p3 in locatie B in bezit 


Coördinator 


Figuur 13.12 
Valse lussen in de globale wacht-graaf 
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heeft, wat tot gevolg heeft dat de pijl (p2,p3) in B wordt toegevoegd. Als het 
bericht voeg-toe (p2,p3) uit B eerder aankomt dan het bericht verwijder (pi,p2) 
uit A, kan de coördinator na voeg toe (maar vóór verwijder) de valse lus 
(p1, p2, p3} ontdekken. Er kan dan aan het herstel van de impasse worden 
begonnen, hoewel er geen impasse is ingetreden. 

@ Onnodig terugdraaien kan ook het gevolg zijn wanneer er werkelijk een impas- 
se is ingetreden en een slachtoffer is uitgezocht, terwijl tegelijkertijd één van 
de processen voortijdig werd beëindigd om redenen die niets met de impasse 
te maken hebben (zoals het feit dat het proces de hem toegewezen tijd over- 
schrijdt). Stel bijvoorbeeld dat locatie A in figuur 13.10 besluit p2 voortijdig te 
beëindigen. Tegelijkertijd heeft de coördinator een lus ontdekt en p3 als slacht- 
offer aangewezen. Nu worden pz en ps beide teruggedraaid, hoewel alleen p2 
teruggedraaid hoefde te worden. 


We merken op dat dezelfde problemen worden overgeërfd in oplossingen waarbij 
van de andere twee mogelijkheden gebruik wordt gemaakt. 

Laten we nu een gecentraliseerd algoritme voor het opsporen van impasses 
geven, waarbij we mogelijkheid 3 gebruiken; dit algoritme ontdekt alle impasses 
die werkelijk optreden en het ontdekt geen valse impasses. Dit algoritme is af- 
‘komstig van Stuart et al. [1984]. Om te vermijden dat er valse impasses worden 
gemeld, eisen we dat aan verzoeken van verschillende locaties unieke identifi- 
caties (tijdregistraties) worden gehecht. Wanneer proces p; in locatie A om een 
systeemfaciliteit van p; in locatie B verzoekt, wordt er een verzoekbericht met 
tijdregistratie n gestuurd. De pijl (pi, pj, n) wordt aan de lokale wacht-graaf van 
A toegevoegd. De pijl (pi, p;, n) wordt in de lokale wacht-graaf van B alleen dan 
toegevoegd als p; het verzoekbericht ontvangen heeft en niet onmiddellijk de ge- 
wenste systeemfaciliteit kan geven. Een verzoek van p; aan pj in dezelfde locatie 
wordt op de gebruikelijke manier behandeld; met de pijl (pi, pj) worden geen 
tijdregistraties verbonden. Het opsporingsalgoritme is dan: 


1. De coördinator stuurt een beginbericht naar elke locatie in het systeem. 

2. Na ontvangst van dit bericht stuurt een locatie zijn lokale wacht-graaf naar 
de coördinator. Let erop dat elk van deze wacht-grafen alle lokale informatie 
bevat die de locatie over de toestand van de werkelijke graaf heeft. De graaf 
weerspiegelt een momentopname van de toestand van de locatie, maar is niet 
gesynchroniseerd met betrekking tot elke andere locatie. 

3. Wanneer de coördinator van elke locatie antwoord ontvangen heeft, con- 
strueert het een graaf op de volgende manier: 


a. De geconstrueerde graaf bevat voor elk proces in het systeem een hoekpunt 
(een cirkeltje). 

b. De graaf heeft dan en slechts dan een pijl (pi, pj) als 1) er in één van de 
wacht-grafen een pijl (pi, pj) voorkomt, of 2) er in meer dan één wacht-graaf 
een pijl (pi, pj, n) (voor een of andere n) voorkomt. 
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We beweren dat het systeem zich in een impassesituatie bevindt indien er 
in de geconstrueerde graaf een lus voorkomt. Als er geen lus in de geconstrueerde 
graaf voorkomt, was het systeem niet in een impassesituatie toen de uitvoering 
van het algoritme begon. 


Hiërarchische aanpak 

Het gecentraliseerde algoritme voor het opsporen van impasses vereist dat alle 
informatie binnen één proces wordt opgeslagen. Een andere mogelijkheid is dat 
de informatie over de verschillende processen gedistribueerd wordt. Het hiërar- 
chische algoritme voor het opsporen van impasses is een gedistribueerd algoritme. 

Evenals in het geval van de gecentraliseerde aanpak, onderhoudt iedere lo- 
catie zijn eigen lokale graaf. In tegenstelling tot de gecentraliseerde methode ech- 
ter, wordt de globale wacht-graaf over een aantal verschillende coördinatoren 
verspreid. Deze coördinatoren worden volgens een boom gerangschikt, waarbij 
elk blad de lokale wacht-graaf van één enkele locatie bevat. Iedere coördinator 
die geen blad is, onderhoudt een wacht-graaf die relevante informatie van de 
grafen van de coördinatoren in de deelboom daaronder bevat. 

Laat in het bijzonder A, B en C coördinatoren zijn zodanig dat C de laagste 
gemeenschappelijke voorvader is van A en B (C moet uniek zijn, omdat we met 
een boom te maken hebben). Stel dat knooppunt p; voorkomt in de lokale wacht- 
grafen van coördinatoren A en B. Dan moet p; ook vóórkomen in de lokale wacht- 
grafen van: 


1. Coördinator C. 
2. Elke coördinator op het pad van C naar A. 
3. Elke coördinator op het pad van C naar B. 


Bovendien moet, als p; en p; in de wacht-graaf van coördinator D voorkomen en 
er in de wacht-graaf van een van de kinderen van D een pad van p; naar pj bestaat, 
er een pijl (pi, p;) in de wacht-graaf van D voorkomen. 

Bestaat er nu een lus in een van de wacht-grafen, dan zit het systeem in een 
impasse en moeten geschikte maatregelen tot herstel worden genomen. 

Ter toelichting van dit algoritme letten we op het systeem van figuur 13.10. 
Een boom voor dit systeem is afgebeeld in figuur 13.13. Omdat p2 en p3 in A en 
B voorkomen, komen ze ook in C voor. Daar er in A een pad van p2 naar p3 loopt, 
treffen we de pijl (p2, p3) in C aan. Op dezelfde wijze bestaat er een pad van p3 
naar p2 in B en dus komt de pijl (ps, p2) in C voor. Merk op dat de wacht-graaf 
in C een lus bevat, zodat er sprake is van een impasse. 

We hebben nog geen algoritme gegeven voor het construeren en onderhou- 
den van deze hiërarchie van coördinatoren. Dit wordt ter oefening aan de lezer 
overgelaten. 


Volledig gedistribueerde aanpak 
Menasce en Muntz [1979] hebben een gedistribueerd algoritme voorgesteld, 
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Figuur 13.13 
Hiërarchische wacht-graaf 


waarbij elke locatie een wacht-graaf construeert die een deel van de totale graaf 
voorstelt, afhankelijk van het dynamische gedrag van het systeem. De gedachte 
hierachter is dat, als er een impasse bestaat, er in (ten minste) één van de gedeelte- 
lijke grafen een lus zal optreden. Dit algoritme heeft twee ongewenste eigenschap- 
pen. Ten eerste zou het sommige impasses mogelijk niet kunnen ontdekken. Ten 
tweede zou het misschien valse impasses kunnen ontdekken. Gligor-en Shattuck 
[1980] hebben een wijziging van het algoritme voorgesteld om het eerste probleem 
op te lossen. Zij merkten ook op dat het gewijzigde algoritme te duur is om 
praktisch bruikbaar te zijn. Obermarck [1982] stelde een andere gedistribueerde 
methode voor, waarbij ook weer in iedere locatie deelgrafen worden gecon- 
strueerd. Dit algoritme gaat eveneens mank aan het probleem dat er valse impas- 
ses gemeld kunnen worden. 


13.10 Robuustheid 


Een gedistribueerd systeem kan hinder ondervinden van verschillende soorten 
storingen in de apparatuur. Het uitvallen van een verbinding, het uitvallen van 
een processor en het verloren gaan van een bericht zijn de meest voorkomende 
storingen. Om robuust te zijn moet het systeem elk van deze storingen opsporen, 
het systeem zo herconfigureren dat de verwerking kan doorgaan en zich herstellen 
wanneer een processor of een verbinding is gerepareerd. 
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13.10.1 Het opsporen van storingen 


In een omgeving waarin geen gemeenschappelijk gebruik gemaakt wordt van het 
geheugen, is het in het algemeen niet mogelijk onderscheid te maken tussen het 
uitvallen van een verbinding, het uitvallen van een processor of het verlies van 
een bericht. We kunnen er gewoonlijk wel achter komen dat een van deze storin- 
gen is opgetreden, maar misschien zijn we niet in staat te ontdekken welk soort 
storing het is. Is een storing eenmaal opgespoord, dan moet, afhankelijk van het 
soort toepassing, de juiste actie worden ondernomen. 

Om het uitvallen van een verbinding en een processor te ontdekken wordt 
gebruik gemaakt van een aansluitingsbevestigingsprocedure (Engels: hand shaking 
procedure). Stel dat de processoren A en B een directe fysieke verbinding met 
elkaar hebben. Met regelmatige tussenpozen zenden beide processoren een Ik- 
ben-er-nog bericht. Als processor A dit bericht niet binnen een vooraf vastgestelde 
tijd ontvangt, kan hij ervan uitgaan dat processor B is uitgevallen, óf dat de 
verbinding tussen A en B is uitgevallen, óf dat het bericht uit B verloren is gegaan. 
Op dit punt gekomen heeft processor A de keus uit twee mogelijkheden. Het kan 
nog zo’n periode wachten op de ontvangst van een Ik-ben-er-nog bericht uit B, 
óf hij kan een Bent-u-er-nog? bericht naar B sturen. 

Als processor A geen Ik-ben-er-nog bericht en geen antwoord op zijn na- 
vraag ontvangt, kan de gehele procedure worden herhaald. Het enige dat proces- 
sor A met zekerheid kan concluderen is dat er een of andere storing is opgetreden. 

Processor A kan proberen erachter te komen of er een storing in de verbin- 
ding of in een processor is opgetreden, door via een andere route (als die bestaat) 
een Bent-u-er-nog? bericht naar B te sturen. Als en wanneer B dit bericht ont- 
vangt, stuurt hij onmiddellijk een positief antwoord terug. Dit positieve antwoord 
zegt A dat B er nog is en dat de storing in de directe verbinding tussen beide zit. 
Daar het niet van tevoren valt te zeggen hoe lang het bericht erover zal doen om 
van A naar B en terug te reizen, moet een blokkeertijd (timeout) worden gebruikt. 
Op het moment dat A het Bent-u-er-nog? bericht stuurt, geeft hij een tijdsinterval 
op gedurende hetwelk hij bereid is op het antwoord van B te wachten. Als A het 
antwoordbericht binnen dat tijdsinterval ontvangt, kan hij veilig concluderen dat 
B in bedrijf is. Als hij echter het antwoordbericht niet binnen het tijdsinterval 
ontvangt (dat wil zeggen, de pauze is verstreken), kan A slechts de conclusie 
trekken dat er één of meer van de volgende situaties zijn opgetreden: 


1. Processor B is uitgevallen. 

2. De directe verbinding (als die bestaat) tussen A en B is uitgevallen. 
3. Het alternatieve pad van A naar B is uitgevallen. 

4, Het bericht is verloren gegaan. 


Processor A kan echter niet vaststellen welke van de bovenstaande situaties wer- 
kelijk is opgetreden. 
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13.10.2 Herconfiguratie 


Stel dat processor A, met behulp van het boven besproken mechanisme, heeft 
ontdekt dat er een storing is opgetreden. Hij moet dan een procedure in werking 
stellen die het systeem de mogelijkheid biedt te herconfigureren en verder te gaan 
met zijn normale wijze van verwerking. 


@ Als een directe verbinding tussen A en B is uitgevallen, moet deze informatie 
aan elke processor in het systeem worden medegedeeld, zodat de verschillende 
route-tabellen daarmee in overeenstemming kunnen worden gebracht. 

@ Als er reden is om aan te nemen dat een processor is uitgevallen (omdat men 
deze niet meer kan bereiken), moeten alle processoren in het systeem daarvan 
op de hoogte worden gesteld, zodat zij niet langer zullen proberen van de 
diensten van de uitgevallen processor gebruik te maken. Het uitvallen van een 
processor die dienst doet als centrale coördinator van een activiteit (zoals het 
opsporen van impasses), vereist dat er een nieuwe coördinator gekozen wordt. 
Evenzo moet, als de processor deel van een logische ring uitmaakt, een nieuwe 
logische ring worden geconstrueerd. Let erop dat, als de processor niet is uit- 
gevallen (dat wil zeggen, hij is in bedrijf maar kan niet worden bereikt), we de 
ongewenste situatie kunnen hebben dat twee processoren als coördinator 
dienst doen. Wanneer het netwerk in twee delen uiteengevallen is, kunnen de 
twee coördinatoren (elk voor zijn eigen deel) tegenstrijdige acties ondernemen. 
Als bijvoorbeeld de coördinatoren verantwoordelijk zijn voor het implemen- 
teren van wederzijdse uitsluiting, kunnen we een situatie aantreffen dat twee 
processen tegelijk in hun kritieke secties aan hun uitvoering bezig zijn. 


13.10.3 Heropname in het systeem na een storing 


Wanneer een uitgevallen verbinding of processor gerepareerd is, moet deze 
elegant en geleidelijk weer binnen het systeem worden opgenomen. 


a. Een verbinding tussen A en B is uitgevallen. Wanneer deze gerepareerd is 
moeten zowel A als B daarvan op de hoogte gesteld worden. Dit op de hoogte 
stellen kan worden bereikt door voortdurend de aansluitingsbevestigingspro- 
cedure die in paragraaf 13.10.1 beschreven werd te herhalen. 

b. Processor B is uitgevallen. Wanneer deze hersteld is, moet hij alle andere 
processoren meedelen dat hij weer in bedrijf is. Processor B kan dan diverse 
soorten informatie van de andere processoren moeten ontvangen voor het 
bijwerken van zijn lokale tabellen, zoals routebepalingsinformatie, een lijst 
van processoren die uitgevallen zijn, of niet aangekomen berichten en post. 
Let erop dat, als de processor niet is uitgevallen maar gewoon niet bereikt 
kon worden, deze informatie nog steeds vereist is. 
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13.11 Het bereiken van overeenstemming 


Wil een systeem betrouwbaar zijn, dan hebben we een mechanisme nodig dat een 
stel processen de gelegenheid biedt een gemeenschappelijke ’waarde’ overeen te 
komen. Er zijn tal van redenen waarom zo’n overeenstemming niet tot stand 
hoeft te komen. Ten eerste kan het communicatiemedium storingen vertonen, 
wat tot gevolg heeft dat berichten verloren gaan of verminkt aankomen. Ten 
tweede kunnen de processen zelf storingen vertonen, wat tot gevolg heeft dat het 
gedrag van het proces onvoorspelbaar wordt. In dit geval is het beste waarop we 
kunnen hopen dat de processen op een nette manier in de fout gaan en met hun 
uitvoering stoppen zonder af te wijken van hun normale uitvoeringspatroon. In 
het ergste geval kunnen processen verminkte of incorrecte berichten naar andere 
processen sturen, of zelfs met andere processen die storingen vertonen samenwer- 
ken, waarbij de integriteit van het systeem al gauw in gevaar komt. 

Dit probleem heeft men aangeduid als het Probleem van de Byzantijnse Ge- 
neraals [Lamport et al. 1982]. Verschillende divisies van het Byzantijnse leger, 
waarbij elk onder het bevel van zijn eigen generaal staat, hebben een vijandelijk 
kamp omsingeld. De Byzantijnse generaals moeten er overeenstemming over be- 
reiken of ze de vijand bij het aanbreken van de dag al of niet zullen aanvallen. 
Het is van essentieel belang dat alle generaals met elkaar overeenstemming berei- 
ken, omdat een aanval door slechts enkele divisies de nederlaag tot gevolg zou 
hebben. De verschillende divisies zijn geografisch verspreid en de generaals kun- 
nen alleen met elkaar communiceren via boodschappers die van kamp tot kamp 
draven. Er zijn ten minste twee belangrijke redenen waarom het kan gebeuren 
dat de generaals geen overeenstemming bereiken: 


@ Boodschappers kunnen door de vijand gevangen genomen worden, waardoor 
ze niet in staat zijn hun berichten af te leveren. Dit correspondeert met onbe- 
trouwbare communicatie in een computersysteem en wordt verder in paragraaf 
13.11.1 besproken. 

@ Generaals kunnen verraders zijn en proberen de loyale generaals te verhinderen 
overeenstemming te bereiken. Dit correspondeert met processen in een com- 
putersysteem die storingen vertonen en wordt verder besproken in paragraaf 
Tad 


13.11.1 Onbetrouwbare communicatie 


Laten we aannemen dat als processen in de fout gaan, zij dit op een nette manier 
doen, en dat het communicatiemedium onbetrouwbaar is. Stel dat proces p; in 
locatie A, dat een bericht heeft verstuurd naar proces p; in locatie B, moet weten 
of p; het bericht goed ontvangen heeft, zodat het kan beslissen hoe het met zijn 
verwerking verder moet gaan. Bijvoorbeeld, p; kan besluiten een functie S te be- 
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rekenen als p; zijn bericht heeft ontvangen, of een functie F te berekenen als Pi 
het bericht niet heeft ontvangen (wegens een of andere storing in de apparatuur). 

Voor het opsporen van storingen kan een blokkeertijd-methode worden ge- 
bruikt, zoals die welke werd beschreven in paragraaf 13.10.1. Wanneer pi een 
bericht verstuurt, specificeert p; ook hoe lang het bereid is te wachten op een 
bevestiging van de ontvangst door pj. Wanneer p; het bericht ontvangt zendt het 
onmiddellijk een bevestiging naar p;. Als p; het bevestigingsbericht binnen het 
gespecificeerde tijdsinterval ontvangt, kan het veilig de conclusie trekken dat p; 
zijn bericht heeft ontvangen. Als echter de pauze verstreken is, moet p; zijn be- 
richt opnieuw versturen en op bevestiging wachten. Deze procedure wordt her- 
haald totdat p; óf de ontvangstbevestiging terugkrijgt, óf van het systeem de me- 
dedeling krijgt dat processor B uitgevallen is. In het eerste geval zal het S bereke- 
nen, terwijl het in het laatste geval F zal berekenen. Merk op dat als dit de enig 
mogelijke alternatieven zijn, p; moet wachten tot het de mededeling krijgt dat een 
van de twee situaties is opgetreden. 

Stel nu dat p; eveneens moet weten dat p; zijn bevestigingsbericht heeft ont- 
vangen, om uit te maken hoe het zijn verwerking moet vervolgen. Met andere 
woorden, p; en p; zullen alleen dan S berekenen als beiden het hierover eens zijn 
geworden. Het blijkt dat in geval van een storing het niet mogelijk is deze taak 
uit te voeren. Precieser uitgedrukt, het is in een gedistribueerde omgeving voor 
de processen p; en p; niet mogelijk volledige overeenstemming te bereiken aan- 
gaande hun respectieve toestanden. 

Laten we deze bewering bewijzen. Stel dat er een minimumreeks van berich- 
tenoverdrachten bestaat zodanig dat, nadat de berichten zijn afgeleverd, beide 
processen overeenstemmen S te berekenen. Laat m’ het laatste bericht zijn dat 
door pi naar pj gezonden is. Aangezien p; niet weet of zijn bericht p; zal bereiken 
(omdat het bericht wegens een storing verloren kan gaan), zal p; S berekenen 
ongeacht of het bericht afgeleverd is of niet. Daarom zou m’ uit de reeks verwij- 
derd kunnen worden zonder dat dat iets aan de beslissingsprocedure toe of af 
doet. Daaruit volgt dat de oorspronkelijke reeks niet een minimumreeks was, wat 
in tegenspraak is met onze veronderstelling en dus aantoont dat zo’n mimimum- 
reeks niet bestaat. De processen kunnen er dus nooit zeker van zijn dat beide S 
zullen berekenen. 


13.11.2 Processen met storing 


Laten we ervan uitgaan dat het communicatiemedium betrouwbaar is, maar dat 
processen onvoorspelbare storingen kunnen vertonen. Beschouw een systeem met 
n processen waarvan er niet meer dan m storingen vertonen. Stel dat elk proces 
pi een of andere eigen waarde W; heeft. We willen een algoritme ontwerpen dat 
elk proces dat geen storingen vertoont een vector X; = (Ai, Aiz ..., Ain) laat 
construeren zodanig dat: 
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a. Als p; een proces is zonder storingen, dan geldt: Ai; = Wj. 
b. Als p; en p; allebei processen zonder storingen zijn, dan geldt: X; = Xj. 


Er zijn een aantal oplossingen voor dit probleem, dat in de literatuur wordt aan- 
geduid als het Probleem van de Byzantijnse Generaals, die alle de volgende eigen- 
schappen gemeen hebben: 


1. Er kan alleen een correct algoritme worden ontworpen als n > 3Xm + 1. 

2. In het ongunstigste geval is de vertraging nodig voor het bereiken van overeen- 
stemming evenredig met de vertraging als gevolg van het zenden van m +1 
berichten. 

3. Het aantal berichten dat vereist is voor het bereiken van overeenstemming is 
erg groot. Dit berust op het feit dat geen enkel proces vetrouwd kan worden, 
zodat alle processen alle informatie moeten verzamelen en hun eigen beslissin- 
gen moeten nemen. 


In plaats van een algemene oplossing te geven, die erg gecompliceerd is, 
zullen we een algoritme geven voor het simpele geval dat m = 1 enn = 4. De 
algemene oplossing kan men vinden in [Pease et al. 1980]. 

Het algoritme vereist twee ronden van informatie-uitwisseling. 


@ Elk proces zendt zijn eigen waarde naar de andere vier processen. 
@ Elk proces zendt de informatie die het in de eerste ronde heeft verkregen naar 
alle andere processen. 


Een proces dat storingen vertoont kan natuurlijk weigeren berichten te zenden. 
In dit geval kan een storingsvrij proces een willekeurige waarde kiezen en net 
doen alsof die waarde door dat proces was verstuurd. 

Zijn deze twee ronden eenmaal voltooid, dan kan een storingsvrij proces pi 
zijn vector X; = (Ai,1, Ai,2, Ai,3, Aia) als volgt construeren: 


a. Ai,i = Wi. 

b. Voor j ¥ i, als voor proces pj ten minste twee van de drie waarden die (in de 
twee uitwisselingsronden) gemeld zijn met elkaar overeenstemmen, wordt de 
grootste waarde gebruikt als de waarde voor Aij. Anders wordt een stan- 
daardwaarde, zeg nul, gebruikt als de waarde voor Aij. 


13.12 Verkiezingsalgoritmen 


Zoals in paragraaf 13.8.1 werd uiteengezet, gebruiken vele algoritmen in gedistri- 
bueerde systemen een coördinator-proces dat de functies verricht die nodig zijn 
voor de andere processen in het systeem. Tot deze functies behoren onder meer 
het opleggen van wederzijdse uitsluiting, het onderhouden van een globale wacht- 
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graaf voor het opsporen van impasses en het besturen van een in- of uitvoereen- 
heid in het systeem. Als het coördinator-proces uitvalt wegens het uitvallen van 
de processor waarin het proces verblijft, kan het systeem de uitvoering alleen 
vervolgen door een nieuwe kopie van de coördinator in een andere processor te 
starten. De algoritmen die bepalen waar een nieuwe kopie van de coördinator 
moet worden gestart, worden verkiezingsalgoritmen genoemd. 

Verkiezingsalgoritmen gaan ervan uit dat met elk proces in het systeem een 
uniek prioriteitsgetal is verbonden. Om de notatie eenvoudig te houden zullen 
we aannemen dat het prioriteitsgetal van proces p; gelijk is aan i. Ook gaan we, 
om onze bespreking simpel te houden, uit van een 1-1-relatie tussen processen 
en processoren, zodat we naar beide kunnen verwijzen met de naam ‘processen’. 
De coördinator is altijd het proces met het hoogste prioriteitsgetal. Daarom moet 
het algoritme, wanneer een coördinator uitvalt, dat actieve proces selecteren dat 
het hoogste prioriteitsgetal heeft. Dit getal moet dan naar elk actief proces in het 
systeem gestuurd worden. Bovendien moet het algoritme een mechanisme leveren 
waarmee een hersteld proces de momentele coördinator kan identificeren. 

In deze paragraaf geven we twee interessante voorbeelden van verkiezings- 
algoritmen voor twee verschillende configuraties van gedistribueerde systemen. 
Het eerste algoritme is van toepassing op systemen waarin elk proces een bericht 
naar elk ander proces in het systeem kan zenden. Het tweede algoritme is van 
toepassing op systemen die als een (logische of fysieke) ring zijn georganiseerd. 
Beide algoritmen vereisen voor een verkiezing n? berichten, waarin n het aantal 
processen in het systeem is. 


13.12.1 Het bully-algoritme 


Stel dat proces p; een verzoek uitzendt dat niet door de coördinator binnen een 
tijdsinterval T beantwoord wordt. In deze situatie wordt aangenomen dat de 
coördinator is uitgevallen en probeert p; zichzelf te verkiezen als de nieuwe coör- 
dinator. Deze taak wordt verricht via het volgende algoritme dat afkomstig is van 
Garcia-Molina [1982]. 

Proces p; stuurt een verkiezingsbericht naar elk proces met een hoger prio- 
riteitsgetal. Proces p; wacht dan gedurende een tijdsinterval T op een antwoord 
van elk van deze processen. 

Als er geen antwoord binnen de tijd T ontvangen is, wordt aangenomen 
dat alle processen met prioriteitsgetallen groter dan i zijn uitgevallen en kiest p; 
zichzelf als de nieuwe coördinator. Proces p; start een nieuwe kopie van de coör- 
dinator en stuurt een bericht uit om alle actieve processen met prioriteitsgetallen 
kleiner dan i ervan op de hoogte te stellen dat p; het nieuwe coördinator-proces 
is. 

Wordt er echter een antwoord ontvangen, dan kijkt p; of het binnen een 
tijd T’ een bericht ontvangt met de mededeling dat een proces met een hoger 
prioriteitsgetal is verkozen. (Een ander proces kiest zichzelf tot coördinator en 
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moet de resultaten binnen de tijd 7’ melden.) Als binnen de tijd T’ geen bericht 
ontvangen is, wordt aangenomen dat het proces met hoger prioriteitsgetal is uit- 
gevallen en moet proces p; het algoritme opnieuw beginnen. 

Op elk willekeurig moment tijdens de uitvoering kan p; een van de volgende 
twee berichten van proces p; ontvangen: 


a. pj is de nieuwe coördinator (j > i). Proces p: op zijn beurt noteert deze infor- 
matie. 

b. p; begon een verkiezing (j < i). Proces p: zendt antwoord naar p; en begint 
zijn eigen verkiezingsalgoritme, mits p; niet al zo’n verkiezing heeft gestart. 


Het proces dat zijn algoritme voltooit heeft het hoogste getal en wordt tot coör- 
dinator gekozen. Het heeft zijn getal naar alle actieve processen met kleinere 
getallen gestuurd. Nadat een uitgevallen proces hersteld is, begint het onmiddel- 
lijk hetzelfde algoritme uit te voeren. Als er geen actieve processen met hogere 
getallen zijn, dwingt het herstelde proces alle processen met lagere getallen zich- 
zelf het coördinator-proces te laten worden, zelfs als er op dat moment een coör- 
dinator actief is met een lager getal. Om deze reden wordt het het bully-algoritme 
genoemd (het Engelse ’bully’ betekent ’bullebak’, ‘vechtersbaas’. 

Laten we de werking van het algoritme toelichten aan de hand van een 
eenvoudig voorbeeld van een systeem dat uit de processen pı tot en met pa be- 
staat. De bewerkingen zijn als volgt: 


1. Alle processen zijn actief, met ps als het coördinator-proces. 

2. pi en p4 vallen uit. pz stelt vast dat pa is uitgevallen door een verzoek te sturen 
dat niet binnen de tijd T beantwoord wordt. p2 begint dan zijn verkiezingsal- 
goritme door een verzoek naar p3 te sturen. 

3. ps ontvangt het verzoek, geeft antwoord aan p2 en begint zijn eigen algoritme 
door een verkiezingsverzoek naar p4 te sturen. 

4. p ontvangt het antwoord van ps en begint gedurende een tijdsinterval T” te 
wachten. 

5. pa antwoord niet binnen de tijd 7; dus ps kiest zichzelf tot coördinator en 
zendt het getal 3 naar p2 en pi (dat door pı niet ontvangen wordt, omdat het 
is uitgevallen). 

6. Later, wanneer pı zich hersteld heeft, zendt het een verkiezingsverzoek naar 
p2, p3 En pa. 

7. p2 en ps geven antwoord aan pı en beginnen aan hun eigen verkiezingsalgorit- 
men. ps zal opnieuw gekozen worden op grond van dezelfde gebeurtenissen 
als hiervoor. 

8. Tenslotte herstelt ps zich en deelt pi, p en ps mede dat hij de momentele coör- 
dinator is. (ps zendt geen verkiezingsverzoeken, omdat het het proces is met 
het hoogste getal in het systeem.) 


13.13 Samenvatting 


13.12.2 Een ring-algoritme 


Dit algoritme gaat ervan uit dat de verbindingen eenrichtingsverkeer kennen en 
dat processen hun berichten naar hun rechterburen zenden. Het algoritme is te 
danken aan Le Lann [1977]. De belangrijkste gegevensstructuur die door het al- 
goritme wordt gebruikt is de actieve lijst, een lijst die de prioriteitsgetallen van 
alle actieve processen in het systeem bevat wanneer het algoritme eindigt; elk 
proces onderhoudt zijn eigen actieve lijst. Het algoritme werkt als volgt. 


1. Als proces p; ontdekt dat de coördinator is uitgevallen, zet het een nieuwe 
actieve lijst op die aanvankelijk leeg is. Dan zendt het een bericht kies(i) naar 
zijn rechterbuur en voegt het getal i aan zijn actieve lijst toe. 

2. Als p: een bericht kies(j) van het proces links van hem ontvangt, moet het op 
een van de volgende drie manieren antwoorden: 

a. Als dit het eerste kies-bericht is dat het gezien of verstuurd heeft, zet p; een 
nieuwe actieve lijst op met de getallen i en j. Dan stuurt het het bericht 
kies(i) uit, gevolgd door het bericht kies(j). 

b. Als i # j (dat wil zeggen, het ontvangen bericht bevat niet het getal van 
pi), dan voegt p: het getal j aan zijn actieve lijst toe en stuurt het bericht 
door naar zijn rechterbuur. 

c. Als i = j (dat wil zeggen, p: ontvangt het bericht kies(i)), dan bevat de 
actieve lijst voor p; nu de getallen van alle actieve processen in het systeem. 
Proces p; kan nu het grootste getal in de actieve lijst vaststellen en zo het 
nieuwe coördinator-proces identificeren. 


Dit algoritme geeft niet aan hoe een proces dat zich aan het herstellen is 
het getal van het huidige coördinator-proces bepaalt. Eén oplossing zou zijn dat 
we eisen dat het zich herstellende proces een navraagbericht stuurt. Dit bericht 
wordt door de ring gestuurd naar de huidige coördinator, die op zijn beurt een 
antwoord stuurt dat zijn getal bevat. 


13.13 Samenvatting 


Een gedistribueerd systeem is een verzameling processsoren die geen gemeen- 
schappelijk gebruik maken van een geheugen of een klok. In plaats daarvan heeft 
iedere processor zijn eigen lokale geheugen en de processoren communiceren met 
elkaar via diverse communicatielijnen, zoals snelle hoofdtransmissielijnen of te- 
lefoonlijnen. De processoren in een gedistribueerd systeem verschillen in grootte 
en in functie. Daaronder kunnen zich microprocessoren bevinden, werkstations, 
minicomputers en grote computersystemen voor algemene doeleinden. 

In principe zijn er twee soorten gedistribueerde systemen: computernetwer- 
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ken en lokale netwerken (Local Area Networks; LAN’s). Het belangrijkste ver- 
schil tussen de twee ligt in de manier waarop deze geografisch gespreid zijn. Com- 
puternetwerken zijn opgebouwd uit een aantal autonome processoren die over 
een groot geografisch gebied (zoals de Verenigde Staten) verspreid staan, terwijl 
lokale netwerken zijn opgebouwd uit processoren die over een klein geografisch 
gebied verspreid zijn, zoals een enkel gebouw of een aantal aangrenzende gebou- 
wen. 

De processoren in het systeem staan met elkaar in verbinding via een com- 
municatienetwerk dat op een aantal verschillende manieren geconfigureerd kan 
zijn. Het netwerk kan geheel of gedeeltelijk verbonden zijn. Het kan een boom- 
structuur hebben, stervormig zijn, of een ring of hoofdtransmissielijn met meer- 
voudige toegang zijn. Het ontwerp van het communicatienetwerk moet rekening 
houden met route- en verbindingsstrategieën en ook met de problemen van wed- 
ijver en veiligheidszekerheid. 

Een gedistribueerd systeem biedt de gebruiker toegang tot de verschillende 
systeemfaciliteiten die het systeem levert. De toegang tot een systeemfaciliteit die 
gemeenschappelijk gebruikt wordt kan worden verleend door gegevensverplaat- 
sing, verwerkingsverplaatsing of job-verplaatsing. Een gedistribueerd bestands- 
systeem moet met twee belangrijke kwesties rekening houden: transparantheid 
(benadert een gebruiker alle bestanden op dezelfde manier ongeacht waar deze 
zich in het netwerk bevinden?) en lokaliteit (waar bevinden de bestanden zich in 
het systeem?) 

In een gedistribueerd systeem zonder gemeenschappelijk geheugen of ge- 
meenschappelijke klok, is het soms onmogelijk de exacte volgorde vast te stellen 
waarin twee gebeurtenissen zich voordoen. De eerder-gebeurd-relatie is slechts 
een gedeeltelijke ordening van gebeurtenissen in gedistribueerde systemen. Men 
kan van tijdregistraties gebruik maken om wederzijdse uitsluiting en het opspo- 
ren van impasses te implementeren. Alternatieve gedistribueerde algoritmen zijn 
onder andere: het merkteken-doorgeef-algoritme voor het synchroniseren van 
een netwerk met een ringstructuur en een hiërarchisch algoritme voor het opspo- 
ren van impasses. 

Een gedistribueerd systeem kan last hebben van diverse soorten storingen 
in de apparatuur. Wil het systeem foutbestendig zijn, dan moet het storingen 
ontdekken en het systeem herconfigureren. Wanneer de storing is verholpen, 
moet het systeem opnieuw geconfigureerd worden. Men kan twee algoritmen ge- 
bruiken, het bully-algoritme en een ring-algoritme, om in geval van storingen een 
nieuwe coördinator te kiezen. 


Opgaven 


13.1 Wat zijn de belangrijkste verschillen tussen een computernetwerk en een 
lokaal netwerk? 


Bibliografische verwijzingen 


13.2 


13.3 


13.4 


13.5 


13.6 


13.7 


13.8 


13.9 


13.10 


13.11 


Vergelijk de verschillende netwerk-topologieén naar hun betrouwbaar- 
heid. 


Waarom gebruiken de meeste computernetwerken slechts een gedeelte- 
lijk-verbonden topologie? 


Wat zijn de voor- en nadelen van het transparant maken van het com- 
puternetwerk voor de gebruiker? 


Vergelijk een gecentraliseerd bestandssysteem en een gedecentraliseerd 
bestandssysteem en ga de verschillen na tussen deze beide. 


Is het altijd van essentieel belang te weten dat het bericht dat u gestuurd 
heeft veilig op zijn bestemming is aangekomen? Zo ja, leg uit waarom. 
Zo niet, geef dan toepasselijke voorbeelden. 


Uw maatschappij bouwt een computernetwerk en men vraagt u een algo- 
ritme te schrijven om wederzijdse uitsluiting te bereiken. Welke methode 
zou u volgen en waarom? 


Geef een algoritme voor het reconstrueren van een logische ring voor het 
geval dat een proces in de ring uitvalt. 


Uw maatschappij bouwt een computernetwerk en men vraagt u een me- 

thode te ontwikkelen om het impasseprobleem aan te pakken. 

a. Zou u een methode voor het opsporen van impasses gebruiken of een 
methode ter voorkoming van impasses? 

b. Als u een methode ter voorkoming van impasses zou kiezen, welke 
zou u dan gebruiken en waarom? 

c. Als u een methode voor het opsporen van impasses zou kiezen, welke 
zou u dan gebruiken en waarom? 


Schrijf een algoritme voor het onderhouden van de hiérarchische metho- 
de voor het opsporen van impasses, zoals die in paragaraaf 13.9.2 is uit- 
eengezet. 


Waarom is het opsporen van impasses in een gedistribueerde omgeving 
veel duurder dan in een gecentraliseerde omgeving? 


Bibliografische verwijzingen 


Kahn [1972], Pyke [1973], Enslow [1973], Doll [1974] en Crowther et al. [1975] 
hebben algemene overzichten van computernetwerken gegeven. Een grondige be- 
spreking van verschillende van de eerste netwerken is gegeven door Peterson en 
Veit [1971]. Forsdick et al [1978], Donnelley [1979] en Ward [1980] hebben bestu- 
ringssystemen voor computernetwerken besproken. 

In de laatste paar jaar zijn een groot aantal privé-computernetwerken en 
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openbare computernetwerken verschenen, zoals het Arpanet [McQuillan en Wal- 
den 1977], Tymenet [Kopf 1977], Datapac [McGibbon et al. 1978], Telenet [New- 
port en Kaul 1977], het Scandinavische Public Data Network [Larsson 1976] en 
Transpac [Danet et al. 1976]. 

Besprekingen aangaande lokale netwerken (LAN’s) zijn geschreven door 
Metcalfe en Boggs [1976] en Clark et al. [1978]. Een speciale uitgave van Compu- 
ter Networks, december 1979, bevatte onder meer negen artikelen over LAN’s, 
waarin onderwerpen aan de orde kwamen als apparatuur, programmatuur, si- 
mulatie en voorbeelden. Een systematiek en uitgebreide lijst van LAN’s is ge- 
geven door Thurber en Freeman [1980]. Farber en Larson [1972], Pierce [1972], 
Fraser [1975], Clark et al. [1978], Liu [1978], Needham [1979] en Wilkes en Whee- 
ler [1979] hebben diverse soorten LAN’s met een ringstructuur besproken. 

Feng [1981] geeft een overzicht van de verschillende netwerk-topologieén. 
Boorstyn en Frank [1977], Gerla en Kleinrock [1977] en Schwartz [1977] bespre- 
ken ontwerp-problemen van topologische aard. 

Nutt [1977], Gula [1978] en Jones en Schwarz [1980] bespreken multiver- 
werking. Een overzicht aangaande multiprocessor-organisatie is geschreven door 
Enslow [1977]. Een bespreking van multiprocessor-apparatuur werd gegeven 
door Satyanarayanan [1980a, 1980b]. Kimbleton en Schneider [1975] en Forsdick 
et al. [1978] leveren een overzicht van computernetwerken. 

Besprekingen over gedistribueerde bestandssystemen worden geboden door 
Gien [1978] (protocol voor het overbrengen van bestanden; Engels: File Transfer 
Protocol, FTP), Israel et al. [1978] en Sturgis et al. [1980] (algemene besprekingen 
met betrekking tot het ontwerp en het gebruik van gedistribueerde bestandssys- 
temen), Swinehart et al. [1979] (het Woodstock-bestandssysteem), Birrel en 
Needham [1980] (een universele bestandsdienstverlener), Dion [1980], (de Cam- 
bridge-bestandsdienstverlener), Fridrich en Older [1981] (de FELIX-bestands- 
dienstverlener), Casey [1972] en Chu [1969] (bestandstoewijzing in een gedistri- 
bueerde omgeving). 

Rivest et al. [1978], Diffie en Hellman [1979], Lempel [1979], Simmons 
[1979], Davies [1980] en Denning [1982b] houden zich bezig met het gebruik van 
cryptografie in computersystemen. 

Het eerste algemene algoritme voor het implementeren van wederzijdse uit- 
sluiting in een gedistribueerde omgeving is afkomstig van Lamport [1978a]; dit 
algoritme vereist 3 X n berichten per ingang. Een verfijning van dit algoritme door 
Ricart en Agrawala [1981] bracht het aantal berichten terug tot de ondergrens 
van 2Xn berichten. Het merteken-doorgeef-algoritme voor systemen met een 
ringstructuur is afkomstig van Le Lann [1977]. 

De kwestie van gedistribueerde synchronisatie is besproken door Reed en 
Kanodia [1979] (omgeving met gemeenschappelijk gebruik van geheugen), 
Banino et al. [1979] (omgeving met gemeenschappelijk gebruik van breedband- 
kanaal), Lamport [1978a, 1978b] en Schneider [1982] (volledig van elkaar geschei- 
den processen). 

Het algoritme voor het opsporen van impasses met behulp van tijdregistra- 
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tie is afkomstig van Rosenkrantz et al. [1978]. De hiërarchische methode is af- 
komstig van Menasce en Muntz [1979]. Een algoritme voor het opsporen van 
impasses waarin de wacht-graaf over het netwerk is gedistribueerd is voorgesteld 
door Menasce en Muntz [1979]. Gligor en Shattuck [1980] toonden aan dat dit 
algoritme incorrect was en zij stelden ook een wijziging in het algoritme voor. 
Obermarck [1982] heeft dit basisalgoritme verder gewijzigd om een beter pres- 
tatievermogen te krijgen. 

Het probleem van het voorkómen en het vermijden van impasses in een 
systeem met pakketschakeling voor het verzenden van gegevens is besproken 
door Merlin en Schweitzer [1980a, 1980b] en Gelernter [1981]. Toueg en Ullman 
[1979] en Toueg [1980] bespreken impassevrije netwerken met pakketschakeling. 
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HET UNIX-BESTURINGSSYSTEEM 


Hoewel men de denkbeelden achter besturingssystemen zuiver theoretisch kan 
beschouwen, is het vaak nuttig om er ook praktische toepassingen van te zien. 
Dit hoofdstuk bevat een diepgaand onderzoek van het 4.2BSD-besturingssys- 
teem, een versie van Unix, als voorbeeld van de verschillende ideeën die in dit 
boek aan de orde zijn gekomen. Door een compleet bestaand systeem aan een 
onderzoek te onderwerpen, zien we de verschillende ideeën die in dit boek zijn 
besproken in hun samenhang met elkaar en met de praktijk. Eerst geven we een 
korte geschiedenis van Unix en daarna bespreken we de koppelingen (Engels: 
interfaces) met de gebruiker en de programmeur. Vervolgens geven we een uiteen- 
zetting van de interne gegevensstructuren en algoritmen die door de Unix-kern 
worden gebruikt om de koppeling met de gebruiker/programmeur te ondersteu- 
nen. 


14.1 Geschiedenis 


De eerste versie van Unix werd in 1969 ontwikkeld door Ken Thompson van de 
Research Group van Bell Laboratories, om van een anders onbenutte PDP-7 
gebruik te kunnen maken. Al spoedig werd hij bijgestaan door Dennis Ritchie. 
Thompson, Ritchie en anderen binnen de Research Group maakten de eerste 
Unix-versies. 

Voordien had Ritchie aan het Multics-project gewerkt en Multics was van 
grote invloed op het nieuwere besturingssysteem. Zelfs de naam Unix is alleen 
maar een woordspeling op Multics. De elementaire organisatie van het bestands- 
systeem, het idee van de commandovertolker (de schil) als een gebruikersproces, 
het gebruik van een afzonderlijk proces voor elk commando, de oorspronkelijke 
tekens voor correctie van ingetypte regels (# om het laatste teken uit te wissen 
en @ om de gehele regel weg te halen) en tal van andere voorzieningen kwamen 
rechtstreeks uit Multics. Ook werd gebruik gemaakt van ideeén uit verschillende 
andere besturingssystemen, zoals CTSS van het MIT en het XDS-940 systeem. 


14.1 Geschiedenis 


Ritchie en Thompson werkten gedurende vele jaren rustig door aan Unix. 
Door hun werk aan de eerste versie konden ze voor een tweede versie een PDP- 
11/20 krijgen. Het herschrijven van het grootste gedeelte van het besturingssys- 
teem in de systeemprogrammeertaal C, in plaats van in de assembleertaal die 
eerst werd gebruikt, leidde tot een derde versie. C werd in Bell Laboratories ont- 
wikkeld om Unix te ondersteunen. Unix werd ook overgebracht naar grotere 
PDP-11 modellen, zoals de 11/45 en de 11/70. Multiprogrammering en andere 
uitbreidingen werden eraan toegevoegd toen het in C herschreven en overge- 
bracht werd naar systemen (zoals de 11/45) die ondersteuning voor multipro- 
grammering in de apparatuur hadden. 
| Naarmate Unix zich ontwikkelde, kreeg het op grote schaal toepassing bin- 

nen Bell Laboratories en gingen geleidelijk ook enkele universiteiten ermee wer- 
ken. De eerste versie die op grote schaal buiten Bell Laboratories beschikbaar 
kwam was Versie 6, in 1976. (Het versienummer voor de eerste Unix-systemen 
correspondeert met het lopende revisienummer van het Unix Programmeurshand- 
boek op het moment dat het systeem werd gedistribueerd; code en handboeken 
werden steeds onafhankelijk van elkaar herzien.) 

In 1978 kwam Versie 7 uit. Dit Unix-systeem draaide op de PDP-11/70 en 
de Interdata 8/32; het is de voorvader van de meeste moderne Unix-systemen. 
Met name werd het al gauw geschikt gemaakt voor andere PDP-11 modellen en 
voor de VAX-computerserie. De versie die op VAX beschikbaar was werd be- 
kend als 32V. | 

Na het uitkomen van Versie 7 in 1978 nam de Groep voor de Ondersteu- 
ning van Unix (Unix Support Group, USG) het administratieve beheer en de 
verantwoordelijkheid over van de Ontwikkelingsgroep (Research Group) voor de 
distributie van Unix binnen AT&T, de moederorganisatie van Bell Laboratories. 
Unix kreeg de status van een produkt, niet alleen maar die van een een stuk 
ontwikkelingsgereedschap. De Research Group ging echter verder met zijn eigen 
versie van Unix ter ondersteuning van hun eigen interne computerverwerking. 
Het systeem dat nu (1985) door de Research Group bij Bell Laboratories wordt 
ontwikkeld is Versie 8. Deze versie is alleen beschikbaar binnen Bell Labora- 
tories. 

De USG gaf voornamelijk ondersteuning voor Unix binnen AT&T. De eer- 
ste uitgave van de USG naar buiten was Systeem III in 1982. Systeem III bevatte 
voorzieningen uit Versie 7, 32V en ook uit verscheidene systemen die door andere 
groepen dan de Research Group waren ontwikkeld. Voorzieningen van UNIX/ 
RT, een systeem voor onvertraagde verwerking (real-time) evenals talrijke stuk- 
ken van de Programmeurs Werkbank (Programmer’s Work Bench, PWB) werden 
in Systeem III opgenomen. 

De USG bracht in 1983 Systeem V uit; dit is eelde afgeleid van Sys- 
teem III. Doordat AT&T de verschillende Bell-bedrijven heeft moeten afstoten, 
is AT&T nu in staat op ambitieuze wijze Systeem V op de markt te brengen. De 
USG is geherstructureerd als het Unix-Systeemontwikkelingslaboratorium (Unix 
System Development Laboratory, USDL), waarvan de huidige uitgave, die werd 
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uitgebracht in 1984, Unix Systeem V Release 2 (V.2) is. (Inmiddels is in 1987 
Systeem V Release 3 uitgebracht — Vert.) 

De kleine omvang, de modulaire opbouw en het gezonde ontwerp van de 
eerste Unix-systemen hebben ertoe geleid dat op Unix gebaseerd werk werd on- 
dernomen door tal van andere instellingen voor informatica, zoals Rand, BBN, 
de Universiteit van Illinois, Harvard, Purdue en zelfs DEC. Buiten de Bell La- 
boratories en de Unix-ontwikkelingsgroepen van AT&T heeft de Universiteit van 
Californië in Berkeley de meeste invloed uitgeoefend. 

Het eerste werk in Berkeley aan Unix voor VAX was het uitbreiden in 1978 
van 32V met virtueel geheugen, pagineren op verzoek en paginavervanging, door 
Bill Joy en Ozalp Babaoglu, die daarmee 3BSD produceerden. De grote virtuele- 
geheugenruimte in 3BSD maakte het ontwikkelen van zeer grote programma’s 
mogelijk, zoals Berkeley's eigen Franz Lisp. Het werk aan het geheugenbeheer 
overtuigde het Bureau voor Geavanceerde Ontwikkelingsprojecten van het Mi- 
nisterie van Defensie (the Defense Advanced Research Projects Agency, DAR- 
PA) ervan dat het de ontwikkeling in Berkeley van een Unix-systeem voor stan- 
daardgebruik door de regering (4BSD) moest financieren. 

Het werk aan 4BSD voor DARPA stond onder leiding van een stuurgroep, 
waartoe vele kopstukken uit de Unix- en netwerkgroepen behoorden. Een van 
de doeleinden van dit project was ondersteuning te verlenen aan de Internet- 
netwerkprotocollen van DARPA (TCP/IP). Deze ondersteuning werd in alge- 
mene vorm gegeven. In 4.2BSD is uniforme communicatie mogelijk tussen diver- 
se onderdelen van een netwerk, met inbegrip van lokale netwerken (zoals Ether- 
net en merkteken-ringnetwerken) en lange-afstand-computernetwerken (zoals 
DARPA’s Arpanet). 

Bovendien heeft Berkeley veel voorzieningen uit hedendaagse besturings- 
systemen aangepast ter verbetering van het ontwerp en de implementatie van 
Unix. Vele van de functies voor terminal-regelopmaak van het TENEX-bestu- 
ringssysteem werden geleverd door een nieuw-ingebouwde terminalbesturing. 
Een nieuwe koppeling naar de gebruiker (de C-schil), een nieuw tekstopmaakpro- 
gramma (ex/vi), compileerprogramma’s voor Pascal en LISP, en veel nieuwe sys- 
teemprogramma’s werden in Berkeley geschreven. Bepaalde verbeteringen in de 
efficiëntie van 4.2BSD waren geïnspireerd door de vergelijking met het VMS- 
besturingssysteem. 

De Unix-programmatuur van Berkeley is uitgegeven in de zogenoemde Ber- 
keley Software Distributions. Gemakshalve verwijst men naar de Berkeley-Unix- 
systemen voor VAX na 3BSD als 4BSD, hoewel er in werkelijkheid diverse speci- 
fieke versies waren, in het bijzonder 4.1BSD en nu ook 4.2BSD (inmiddels 
4.3BSD — Vert.). De generieke getallen 2BSD en 4BSD worden gebruikt voor de 
uitgaven voor de PDP-11 en VAX van Berkeley-Unix. 4.2BSD, voor het eerst 
uitgegeven in 1983, is de bekroning van het oorspronkelijke Unix-project van 
Berkeley voor DARPA, hoewel men in Berkeley doorgaat met het onderzoek. 
2.9BSD is de gelijkwaardige versie voor PDP-11 systemen. 

Figuur 14.1 bevat een overzicht van de betrekkingen tussen de verschillende 
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Geschiedenis van de Unix-versies 


versies van Unix. 

4BSD was het besturingssysteem waarop voor VAX-systemen de keus ge- 
vallen was vanaf de eerste versie (1979) tot de versie van Systeem III (1982). 
4BSD is nog steeds de beste keuze voor veel installaties voor onderzoek en net- 
werken. Veel organisaties kochten een 32V-licentie, om dan 4BSD van Berkeley 
te bestellen zonder nog moeite te doen om de magneetband met 32V erop te 
krijgen. 

De huidige groep van Unix-systemen is echter niet beperkt tot Versie 8, 
Systeem V (Release 2) en 4.2BSD. Naarmate Unix aan populariteit heeft gewon- 
nen, is het naar verschillende computers en computersystemen overgebracht. Er 
is een grote verscheidenheid aan Unix- en Unix-achtige besturingssystemen geko- 
men. DEC ondersteunt zijn Unix (dat Ultrix wordt genoemd) voor VAX-syste- 
men; Microsoft heeft Unix voor de Intel 8088 herschreven en het Xenix ge- 
noemd; IBM heeft Unix op zijn PC en mainframes. Unix wordt ook beschikbaar 
gesteld door Amdahl, Sun, NBI, MassComp, Hewlett-Packard, Gould, Data Ge- 
neral, Perkin-Elmer en een massa andere leveranciers, waaronder natuurlijk 
AT&T. De meeste van deze systemen zijn gebaseerd op Versie 7, Systeem III, 
4.2BSD of Systeem V. (Momenteel, 1987, zijn nagenoeg alle Unix-produkten op 
het niveau van Systeem V gebracht, soms met veel toevoegingen uit 4.2BSD — 
Vert.) 

Wij geloven dat Unix een belangrijk onderdeel van zowel de theorie als de 
praktijk van besturingssystemen is geworden en zal blijven. Unix is een uitste- 
kend hulpmiddel voor academische studie. Zowel bijvoorbeeld het Tunis-bestu- 
ringssysteem [Holt 1983] als het Xinu-besturingssysteem [Comer 1984] zijn geba- 
seerd op de Unix-denkbeelden, maar werden expliciet voor educatieve doelein- 
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den ontwikkeld. Ritchie en Thompson kregen in 1983 de ACM Turing-onder- 
scheiding voor hun werk aan Unix. 

De specifieke versie van Unix die in dit hoofdstuk wordt gebruikt is de 
VAX-versie van 4.2BSD. Dit systeem wordt gebruikt omdat daarin vele belang- 
rijke denkbeelden aangaande besturingssystemen zijn ingebouwd, zoals pagine- 
ren op verzoek en gebruik van een netwerk. De VAX-implementatie wordt ge- 
bruikt omdat 4.2BSD op de VAX werd ontwikkeld en die machine nog steeds 
een handig referentiepunt vormt, ondanks de recente implementaties op andere 
apparatuur (zoals de Motorola 68000 of National 32032). 


14.2 Het Unix-ontwerp 


Unix werd ontworpen als een systeem voor tijddeling. De standaardkoppeling . 
met de gebruiker (de schil) is eenvoudig en kan desgewenst door een andere wor- 
den vervangen. Het bestandssysteem is een boom met meerdere niveaus, waar- 
door het mogelijk is dat gebruikers hun eigen subadresboeken creëren. Alle gege- 
vensbestanden van de gebruiker zijn gewoon een reeks bytes. 

Schijfbestanden en randapparatuur worden zoveel mogelijk op dezelfde 
manier behandeld. Op deze wijze worden afhankelijkheden en bijzondere ken- 
merken van de randapparatuur zoveel mogelijk binnen de kern gehouden; en 
zelfs binnen de kern zijn de meeste daarvan beperkt tot de stuurroutines voor de 
randapparatuur. 

Unix ondersteunt meerdere processen. Een proces kan gemakkelijk nieuwe 
processen in het leven roepen. CVE-werkindeling bestaat uit een eenvoudig algo- 
ritme dat gebaseerd is op prioriteit. Het geheugenbeheer wordt gevormd door 
een algoritme dat gebruik maakt van variabele regio’s (MVT) met programmaver- 
wisseling. 4.2BSD gebruikt pagineren op verzoek als een mechanisme ter onder- 
steuning van het geheugenbeheer en beslissingen over de CVE-werkindeling. 

Unix is een uitstekend voorbeeld van een besturingssysteem voor een per- 
sonal computer. Het werd eerst door één programmeur, Ken Thompson, en later 
nog een, Dennis Ritchie, ontworpen als een systeem voor eigen gebruik. Als zoda- 
nig is het klein genoeg om te begrijpen. De meeste algoritmen werden gekozen 
om hun eenvoud, en niet omdat ze het systeem zo snel of zo slim maken. Het 
gezonde ontwerp ervan heeft tot gevolg gehad dat het vele malen is geïmiteerd 
en gemodificeerd. 

Hoewel de ontwerpers van Unix over een aanzienlijke hoeveelheid kennis 
van andere besturingssystemen beschikten, werd het ontwerp niet in alle details 
omschreven voordat men tot implementatie overging. Deze flexibiliteit blijkt een 
van de hoofdfactoren in de ontwikkeling van het systeem geweest te zijn. Er was 
echter wel sprake van een paar ontwerp-principes, hoewel deze niet nauwkeurig 
vanaf het begin werden omschreven. 

Unix werd door programmeurs voor programmeurs ontworpen. Op deze 
wijze is het altijd interactief geweest en voorzieningen voor programma-ontwik- 
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keling hebben altijd de hoogste prioriteit gekregen. Onder deze voorzieningen 
treft men aan het programma make (dat gebruikt kan worden om een verzameling 
bronbestanden te onderzoeken en te zien welke van deze bestanden voor een 
bepaald programma gecompileerd moeten worden, en om dit dan te doen) en het 
Broncode-besturingssysteem (Source Code Control System, SSCS) (dat gebruikt 
wordt om achtereenvolgende versies van bestanden beschikbaar te houden zon- 
der dat men de gehele inhoud van elke stap hoeft op te slaan). 

Het besturingssysteem is grotendeels geschreven in C, een systeemprogram- 
meertaal. C werd ontwikkeld om Unix te ondersteunen, omdat noch Thompson 
noch Ritchie ervan hielden in assembleertaal te programmeren. Het vermijden 
van het gebruik van assembleertaal was ook nodig omdat men geen zekerheid 
had omtrent de machine of machines waarop Unix gedraaid zou worden. Dit 
heeft de problemen van het overbrengen van Unix van het ene apparatuur-sys- 
teem naar het andere in hoge mate vereenvoudigd. 

Van het begin af aan waren alle Unix-bronnen bij de Unix-ontwikkelings- 
systemen gekoppeld beschikbaar en hebben de ontwikkelaars de systemen in ont- 
wikkeling als hun primaire systemen gebruikt. Dit heeft het ontdekken van gebre- 
ken en de oplossingen daarvoor, evenals nieuwe mogelijkheden en de implemen- 
tatie daarvan, aanzienlijk vergemakkelijkt. Dit heeft ook de overvloed aan Unix- 
varianten die vandaag de dag bestaan gestimuleerd, maar de voordelen hebben 
opgewogen tegen de nadelen: als iets niet goed werkt kan het lokaal gerepareerd 
worden zonder dat men op de volgende versie van het systeem hoeft te wachten. 
Zulke reparaties, evenals nieuwe voorzieningen, kunnen in latere uitgaven inge- 
bouwd worden. 

De beperkte grootte van de PDP-11 (en eerdere computers die voor Unix 
waren gebruikt) hebben een zekere elegantie afgedwongen. Waar andere syste- 
men omslachtige algoritmen hebben om uitzonderlijke situaties aan te kunnen, 
gaat Unix op beheerste wijze plat (dit is dan een paniek-stop), waarbij Unix 
probeert zulke condities te voorkomen in plaats van deze te herstellen. Waar 
andere systemen grof geweld of macro-expansie gebruiken, heeft Unix meestal 
subtielere, of tenminste eenvoudigere, methoden. 


14.3 Koppeling met de programmeur 


Zoals alle computersystemen bestaat Unix uit twee van elkaar te scheiden gedeel- 
ten: de kern en de systeemprogramma’s. Men kan het Unix-besturingssysteem 
ruwweg zien als in lagen opgebouwd, zoals figuur 14.2 laat zien. Alles beneden 
de systeemaanroep-koppeling en boven de fysieke apparatuur is de kern. De kern 
wordt gevormd door het bestandssysteem, de CVE-werkindeling, het geheugen- 
beheer en andere systeemfuncties die bereikbaar zijn via systeemaanroepen. De 
systeemprogramma’s gebruiken de systeemaanroepen die door de kern worden 
ondersteund voor het leveren van nuttige functies, zoals compileren en bestands- 
bewerking. 
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Figuur 14.2 
Gelaagde structuur van 4.2BSD 


Systeemaanroepen definiéren in Unix de koppeling met de programmeur; 
de verzameling systeemprogramma’s die gewoonlijk beschikbaar is definieert de 
koppeling met de gebruiker. De koppeling met de programmeur en die met de 
gebruiker definiëren de context die door de kern moet worden ondersteund. 

De systeemaanroepen worden in VAX 4.2BSD gedaan met behulp van een 
val’ die open gaat naar geheugenplaats 40 van de VAX-onderbrekingsvectoren. 
Er worden parameters aan de kern doorgegeven via de stapel die in de apparatuur 
is ingebouwd; de kern geeft waarden terug in de registers RO en R1. Register RO 
kan als antwoord ook een foutcode bevatten. De waarde van de overdrachtsbit 
bepaalt of er sprake is van een normale terugkeerwaarde of een foutcode. 

Dit detailniveau wordt evenwel zelden door de Unix-programmeur opge- 
merkt. De meeste systeemprogramma’s zijn in C geschreven en het Unix Gebrui- 
kershandboek geeft alle systeemaanroepen weer als C-functies. Een systeempro- 
gramma dat in C geschreven is voor 4.2BSD op de VAX kan in het algemeen naar 
een ander 4.2BSD-systeem worden overgebracht en eenvoudig opnieuw worden 
gecompileerd, ook al kunnen de details van de apparatuur heel verschillend zijn. 
De details van systeemaanroepen zijn alleen aan het compileerprogramma be- 
kend. Dit is een belangrijke reden voor de overdraagbaarheid (Engels: portabi- 
lity) van Unix-programma’s. 

De systeemaanroepen voor Unix kunnen globaal in drie groepen worden 
verdeeld: bestandsbewerking, procesbesturing en bewerking van informatie. In 
hoofdstuk 2 hebben we een vierde groep, besturing van de randapparatuur, ver- 
meld, maar aangezien de randapparaten in Unix als (speciale) bestanden worden 
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behandeld, ondersteunen dezelfde systeemaanroepen zowel bestanden als de 
randapparatuur. 


14.3.1 Bestandsbewerking 


Een bestand is in Unix een reeks bytes. Verschillende programma’s verwachten 
verschillende structuurniveaus, maar de kern legt aan bestanden geen structuur 
op. Voor tekstbestanden is het bijvoorbeeld gebruikelijk dat regels bestaande uit 
ASCII-tekens van elkaar gescheiden zijn door een enkel nieuwe-regelteken, maar 
de kern weet niets van die afspraak. 

Bestanden zijn georganiseerd als adresboeken met een boomstructuur. De 
adresboeken zelf zijn bestanden die informatie bevatten over de vraag hoe men 
andere bestanden moet vinden. Een padnaam voor een bestand is een rij tekens 
die een bestand identificeert door een pad via de adresboekstructuur naar het 
bestand aan te geven. Syntactisch bestaat de padnaam uit afzonderlijke bestands- 
naamelementen die door een schuine deelstreep (slash) van elkaar gescheiden 
zijn. Bijvoorbeeld, in /usr/local/font geeft de eerste schuine deelstreep de wortel 
van de adresboekboom aan, die het worteladresboek wordt genoemd. Het volgen- 
de element, usr, is een subadresboek van de wortel, local is een subadresboek van 
usr en font is een bestand of adresboek in het adresboek local. Of font een gewoon 
bestand is of een adresboek kan niet uit de syntaxis van de padnaam worden 
vastgesteld. 

Unix heeft zowel absolute padnamen als relatieve padnamen. Absolute pad- 
namen beginnen bij de wortel van het bestandssysteem en zijn te herkennen aan 
een schuine deelstreep aan het begin van de padnaam; /usr/local/ font is een ab- 
solute padnaam. Relatieve padnamen beginnen met het actieve adresboek, dat een 
attribuut is van het proces dat tot de padnaam toegang zoekt. Zo geeft local/ font 
een bestand of adresboek met de naam font aan in het adresboek local in het 
actieve adresboek, dat al of niet /usr zou kunnen zijn. 

Een bestand kan onder meer dan één naam in meer dan één adresboek zijn 
geregistreerd. Zulke meervoudige namen worden schakels (Engels: links) ge- 
noemd en alle schakels worden op dezelfde manier door het besturingssysteem 
behandeld. 4.2BSD ondersteunt ook symbolische schakels; dit zijn bestanden die 
de absolute padnaam van een ander bestand bevatten. De twee soorten staan 
ook bekend als harde schakels en zachte schakels. Zachte (symbolische) schakels 
kunnen, in tegenstelling tot harde schakels, naar adresboeken wijzen en over de 
grenzen van bestandssystemen heengaan. 

De bestandsnaam °.’ in een adresboek is een harde schakel naar het adres- 
boek zelf. De bestandsnaam ’… is een harde schakel naar het ouderadresboek. 
Zo verwijst, als het actieve adresboek /user/jlp/programs is, ../bin/ wdf naar 
/user/jlp/bin/wdf. 

Randapparaten hebben namen in het bestandssysteem. Deze randappara- 
tuur-bestanden of speciale bestanden staan bij de kern als randapparatuur-koppe- 
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lingen bekend, maar zijn nochthans voor de gebruiker toegankelijk via veelal 
dezelfde systeemaanroepen als andere bestanden. 

Figuur 14.3 laat een voor Unix kenmerkend bestandssysteem zien. De wor- 
tel (/) bevat gewoonlijk een klein aantal adresboeken plus /vmunix, het binaire 
startbeeld van het besturingssysteem; /dev bevat de randapparatuur-bestanden, 
zoals /dev/console, /dev/Ip0, /dev/mt0 enzovoort; /bin bevat de binaire vormen 
van de belangrijkste Unix-systeemprogramma’s. Andere binaire vormen kunnen 
zich bevinden in /usr/bin (voor ’toepassings’systeemprogramma’s zoals tekstop- 
maakprogramma’s), /usr/ucb (voor systeemprogramma’s die in Berkeley in plaats 
van door AT&T geschreven zijn), of /usr/local/bin (voor systeemprogramma’s 
die op de locatie zelf geschreven zijn). Bibliotheekbestanden, zoals de biblio- 
theek-subroutines van C, Pascal en FORTRAN, worden in /lib (of /usr/lib of 
/usr/local/lib) bewaard. 

De eigen bestanden van de gebruikers worden in een voor iedere gebruiker 
afzonderlijk adresboek, gewoonlijk /user, opgeslagen. Zo bevindt het adresboek 
voor carol zich gewoonlijk in /user/carol. Voor een groot systeem kunnen deze 
adresboeken verder onderverdeeld zijn om de administratie te vergemakkelijken, 
waardoor een bestandsstructuur van het type /user/prof/avi en /user/staff/carol 
ontstaat. Administratieve bestanden en programma’s, zoals het wachtwoordenbe- 
stand, worden in /etc bewaard. Tijdelijke bestanden kunnen in /tmp geplaatst 
worden, dat gewoonlijk eens per dag gewist wordt, of in /usr/tmp. 

Elk van deze adresboeken kan nog aanzienlijk verder gestructureerd zijn. 
Zo worden bijvoorbeeld de font-beschrijvingstabellen voor het troff-opmaakpro- 
gramma voor de fotozetmachine Mergenthaler 202 in /usr/lib/ troff/dev202 be- 
waard. Al deze afspraken over de plaatsing van specifieke bestanden en adresboe- 
ken zijn door programmeurs en hun programma’s gedefinieerd; de kern van het 
besturingssysteem is alleen afhankelijk van het bestaan van /etc/ init, dat gebruikt 
wordt om terminal-processen te initialiseren. 

Systeemaanroepen voor elementaire bestandbewerking zijn creat (creëer), 
open (open), read (lees), write (schrijf), close (sluit) en unlink (verwijder schakel). 
De creat-systeemaanroep maakt op grond van een padnaam een (leeg) bestand 
aan. Een bestand wordt geopend door de open-systeemaanroep, die een padnaam 
en een modus (zoals lees-, schrijf- of lees/schrijf-modus) aanneemt en een klein 
geheel getal teruggeeft dat een bestandsbeschrijver genoemd wordt. De beschrijver 
is een index in een tabelletje van open bestanden voor dit proces. Beschrijvers 
beginnen bij nul en komen voor gangbare programma’s zelden boven de zes of 
zeven uit, afhankelijk van het maximumaantal bestanden dat gelijktijdig open is. 
Een bestandsbeschrijver kan dan aan een read- of write-systeemaanroep worden 
meegegeven (tezamen met een bufferadres en het aantal bytes dat moet worden 
overgebracht) om gegevens naar en van het bestand over te brengen. Een bestand 
wordt gesloten door zijn bestandsbeschrijver aan de close-systeemaanroep mee te 
geven. 

Elke read- of write-systeemaanroep wijzigt de momentele afstand tot het 
begin (Engels: offset) van het bestand, die wordt gebruikt om de positie in het 
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bestand te bepalen voor de volgende read- of write-aanroep. De lseek-systeem- 
aanroep (zoek) maakt het mogelijk deze positie expliciet opnieuw in te stellen. 
Er is nog een systeemaanroep, ioctl (I/O control’: I/O-besturing), voor bewer- 
kingen op de parameters voor de randapparatuur. 

Informatie over het bestand (zoals zijn grootte, beveiligings-modi, eigenaar 
enzovoort) kunnen worden opgevraagd met behulp van de stat-systeemaanroep. 
Er zijn drie systeemaanroepen die ervoor zorgen dat informatie gewijzigd kan 
worden: rename (wijzig de bestandsnaam, herbenoem), chmod (‘change modes’: 
wijzig de beveiligings-modi) en chown (‘change owner: wijzig de eigenaar). De 
link-systeemaanroep (schakel) maakt een harde schakel aan voor een bestaand 
bestand, waarbij voor het bestaande bestand een nieuwe naam bijgemaakt wordt. 
Een schakel wordt weer verwijderd door de unlink-systeemaanroep; als dit de 
laatste schakel is wordt het bestand opgeheven. 

Adresboeken worden aangemaakt door middel van de mkdir-systeemaan- 
roep (make directory’: maak adresboek aan) en ze worden weer opgeheven door 
middel van rmdir (‘remove directory’: verwijder adresboek). Het actieve adres- 
boek wordt gewijzigd met behulp van chdir (change directory’: wijzig adresboek). 


14.3.2 Procesbesturing 


Een proces is een programma in uitvoering. Een proces wordt geïdentificeerd met 
behulp van een procesidentificatiesymbool, dat een geheel getal is. Een nieuw 
proces wordt in het leven geroepen door middel van de fork-systeemaanroep (ver- 
tak), die twee bijna identieke processen creëert, waarbij elk proces een kopie van 
de oorspronkelijke adresruimte bezit: hetzelfde programma en dezelfde varia- 
belen met dezelfde waarden. Beide processen (de ouder en het kind) gaan verder 
met de uitvoering van de instructie na de fork, met één verschil: de terugkeercode 
voor de fork is nul voor het nieuwe proces (het kind), terwijl het procesidentifi- 
catiesymbool (dat niet-nul is) van het kind wordt teruggegeven aan de ouder. 

Het kenmerkende is dat de execve-systeemaanroep door een van de twee 
processen wordt gebruikt na een fork om zijn virtuele-geheugenruimte door een 
nieuw programma te laten vervangen. De execve-systeemaanroep laadt een binair 
bestand in het geheugen (waardoor het geheugenbeeld van het programma dat 
de execve-systeemaanroep bevat wordt overschreven) en begint met de uitvoering 
ervan. 

Een proces kan eindigen door gebruik te maken van de exit-systeemaanroep 
en zijn ouderproces kan op die gebeurtenis wachten met behulp van de wait- 
systeemaanroep (wacht). De wait-systeemaanroep geeft de waarde van het 
procesidentificatiesymbool van een beëindigd kind terug, zodat de ouder weet 
welk kind eindigde. 

De combinatie exit en wait kan men als analoog zien met de abstracte join- 
functie (verbind) uit hoofdstuk 9, evenals de combinatie fork en execve analoog 
is aan de toen besproken abstracte fork-functie (vertak). Gezien vanuit het aan- 


14.3 Koppeling met de programmeur 


roepende proces, komen fork en wait overeen met een subroutine-aanroep en 
terugkeer uit de subroutine (Engels: call en return), terwijl execve meer weg heeft 
van een ’go to’. 

De eenvoudigste vorm van communicatie tussen processen wordt gevormd 
door pipes (pijpen), die vóór de fork gecreëerd kunnen worden en waarvan de 
eindpunten corresponderen met de fork en de execve. Een pijp is in wezen een 
wachtrij van bytes tussen twee processen. Tot de pijp wordt toegang verkregen 
met behulp van een bestandsbeschrijver, zoals bij een normaal bestand. Eén pro- 
ces schrijft in de pijp en het andere leest uit de pijp. De grootte van de pijp 
(gewoonlijk 4096 bytes) is door het systeem vastgelegd. Wanneer een proces leest 
uit een lege pijp of schrijft in een pijp die vol is, wordt het proces geblokkeerd 
totdat de toestand van de pijp zich wijzigt. 

Alle gebruikersprocessen zijn afstammelingen van één oorspronkelijk pro- 
ces, dat init wordt genoemd (en dat het procesidentificatiesymbool 1 heeft). 
ledere terminalpoort die voor interactief gebruik beschikbaar is heeft een getty- 
proces dat door init door middel van een fork in het leven geroepen is. Getty 
initialiseert parameters van de terminallijn en wacht op de login-naam van de 
gebruiker, die het dan als argument via een execve meegeeft aan het login-proces. 
Login pikt dan het wachtwoord van de gebruiker op, codeert het en vergelijkt het 
met een gecodeerde rij tekens die uit het bestand /etc/passwd wordt gehaald. Als 
de vergelijking klopt krijgt de gebruiker toestemming in te loggen. Login voert 
een schil (Engels: shell) of een commandovertolker uit, nadat het het numerieke 
gebruikersidentificatiesymbool van het proces gelijkgemaakt heeft aan dat van de 
gebruiker die inlogt. (De schil en het gebruikersidentificatiesymbool staan in 
etc/passwd achter de login-naam van de gebruiker). Met deze schil communi- 
ceert de gebruiker gewoonlijk gedurende de rest van de login-sessie, terwijl de 
schil zelf via herhaald gebruik van de ’fork’ subprocessen creëert voor uitvoering 
van de commando’s van de gebruiker. 

Het gebruikersidentificatiesymbool wordt door de kern gebruikt om te be- 
palen of de gebruiker toestemming heeft voor bepaalde systeemaanroepen, met 
name die welke te maken hebben met de toegang tot bestanden. Er is ook een 
groepsidentificatiesymbool, dat wordt gebruikt om soortgelijke voorrechten te ver- 
lenen aan een groep van gebruikers. In 4.2BSD kan een proces tegelijkertijd tot 
verschillende groepen behoren. Het login-proces plaatst de schil in alle groepen 
waarvoor toestemming voor de gebruiker blijkt uit de bestanden /etc/passwd en 
/etc/ group. 

Er zijn in werkelijkheid twee gebruikersidentificatiesymbolen die door de 
kern gebruikt worden: het effectieve-gebruikersidentificatiesymbool is het identifi- 
catiesymbool dat gebruikt wordt om te bepalen of toegang tot bestanden is toege- 
staan. Als de setuid-bit in het i-knooppunt van het programmabestand, dat wordt 
geladen als gevolg van een execve, aanstaat, wordt het effectieve-gebruikersidentifi- 
catiesymbool gelijkgesteld aan het gebruikersidentificatiesymbool van de eigenaar 
van het bestand, terwijl het werkelijke-gebruikersidentificatiesymbool onveranderd 
wordt gelaten. Dit biedt de mogelijkheid dat bepaalde processen meer dan de 
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gewone voorrechten hebben, terwijl ze toch door gewone gebruikers uitvoerbaar 
zijn. Het idee van de ’setuid’ (‘set user identification’, ofwel ‘zet gebruikersiden- 
tificatiesymbool’) is een patent van Dennis Ritchie (U.S. patent no. 4.135.240) 
en is een van de markante trekjes van Unix. Er bestaat een soortgelijke setgid 
(set group identification’, ’zet groepsidentificatiesymbool’) voor groepen. 


14.3.3 Signalen 


Signalen vormen een manier om uitzonderlijke condities te behandelen die lijken 
op onderbrekingen door de programmatuur. Er zijn 19 verschillende signalen, 
die elk met een bepaalde conditie corresponderen. Een signaal kan worden ge- 
genereerd door een onderbreking via het toetsenbord, door een fout in een pro- 
ces, zoals een incorrecte geheugenverwijzing, of door een aantal asynchrone ge- 
beurtenissen zoals onderbrekingen door een tijdregister of job-besturingssignalen 
vanuit de schil. Bijna elk signaal kan ook gegenereerd worden door de kill-sys- 
teemaanroep (beëindig; letterlijk: dood). 

Het onderbrekingssignaal SIGINT (signal interrupt’), wordt gebruikt om 
een commando voortijdig af te breken. Gewoonlijk wordt het teweeggebracht 
door het C teken (ASCII 3) of, in traditionelere configuraties, het delete-teken 
(ASCII 127). In 4.2BSD worden de belangrijke tekens van het toetsenbord gedefi- 
nieerd door middel van een tabel voor elke terminal en kunnen deze gemakkelijk 
opnieuw gedefinieerd worden. Het quit-signaal, SIGQUIT, wordt gewoonlijk ge- 
produceerd door het teken (ASCII 28). Het quit-signaal stopt het programma 
dat momenteel wordt uitgevoerd en schrijft een geheugendump van zijn huidige 
geheugenbeeld weg naar een bestand in het actieve adresboek dat core genoemd 
wordt. Het core-bestand kan voor het opsporen van fouten worden gebruikt. 
SIGILL wordt geproduceerd door een illegale instructie en SIGSEGV is het re- 
sultaat van een poging om geheugen te adresseren dat buiten de legale virtuele- 
geheugenruimte van een proces valt. 

Er kunnen regelingen worden getroffen opdat de meeste signalen genegeerd 
worden (geen effect hebben), of opdat er een routine in het gebruikersproces (een 
signaalroutine) wordt aangeroepen. Er is één signaal (het kill-signaal, nummer 
negen, SIGKILL) dat niet genegeerd kan worden en dat niet door een signaalrou- 
tine kan worden opgepakt. SIGKILL wordt bijvoorbeeld gebruikt om een op 
hol geslagen proces dat andere signalen zoals SIGINT of SIGQUIT negeert, te 
beëindigen. 

Signalen kunnen verloren gaan: als eenzelfde soort signaal wordt gestuurd 
voordat een voorgaand signaal door het proces waarvoor het bedoeld is werd 
ontvangen, zal het eerste signaal worden overschreven en zal alleen het laatste 
door het proces worden gezien. 
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14.3.4 Bewerking van informatie 


Er bestaan systeemaanroepen voor het opvragen en zetten van zowel een tijd- 
alarm (getitimer/setitimer) als de momentele tijd in microseconden sinds 1 januari 
1970 gettimeofday/settimeofday). Bovendien kunnen processen hun proces- 
identificatiesymbool opvragen (getpid), hun groepsidentificatiesymbool (getgid), 
de naam van de machine waarop zij worden uitgevoerd (gethostname) en tal van 
andere waarden. 


14.3.5 Bibliotheekroutines 


De systeemaanroepkoppeling met Unix wordt ondersteund en krachtiger ge- 
maakt door een grote verzameling bibliotheekroutines en kopbestanden. De kop- 
bestanden leveren de definitie van complexe gegevensstructuren die in systeem- 
aanroepen worden gebruikt. Bovendien biedt een grote functiebibliotheek extra 
programma-ondersteuning. 

De systeemaanroepen van het I/O-systeem van Unix voorzien bijvoorbeeld 
in het lezen en wegschrijven van blokken bytes. Sommige toepassingen willen 
misschien één byte tegelijk lezen en schrijven. Het zou wel mogelijk zijn om één 
byte tegelijk te lezen en weg te schrijven, maar dan zou voor elke byte een sys- 
teemaanroep nodig zijn, wat een zeer grote extra last betekent. In plaats daarvan 
zorgt een groep standaardbibliotheekroutines (het I/O-pakket met toegang via 
het kopbestand stdio.h) voor een andere koppeling die duizenden bytes tegelijk 
leest en schrijft, waarbij gebruik wordt gemaakt van lokale buffers en overbren- 
ging tussen deze buffers onderling (in het gebruikersgeheugen) wanneer I/O no- 
dig is. Geformateerde I/O wordt ook ondersteund door het standaardpakket 
voor I/O. 

Er worden nog andere vormen van bibliotheekondersteuning gegeven voor 
mathematische functies, toegang tot netwerken, het converteren van gegevens, 
enzovoort. De kern van 4.2BSD ondersteunt 153 systeemaanroepen, terwijl de 
C-programmabibliotheek 336 bibliotheekfuncties heeft. Hoewel de bibliotheek- 
functies uiteindelijk, waar nodig, een systeemaanroep tot gevolg hebben (de get- 
char-bibliotheekroutine bijvoorbeeld heeft een read-systeemaanroep tot gevolg 
als de bestandsbuffer leeg is), is het in het algemeen niet nodig dat de program- 
meur onderscheid maakt tussen de basisgroep van systeemaanroepen van de kern 
en de extra functies die worden geleverd door de bibliotheekroutines. 


14.4 Koppeling met de gebruiker 
Zowel de programmeur als de gebruiker van een Unix-systeem hebben hoofdza- 


kelijk te maken met de groep systeemprogramma’s die zijn geschreven en be- 
schikbaar zijn om te worden uitgevoerd. Deze programma’s doen ter ondersteu- 
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ning van hun functie de noodzakelijke systeemaanroepen, maar de systeemaan- 
roepen zelf liggen binnen het programma, zodat de gebruiker er geen weet van 
hoeft te hebben. 

De veel gebruikte systeemprogramma’s kunnen in verschillende groepen 
worden ingedeeld; de meeste daarvan hebben betrekking op bestanden en adres- 
boeken. Voor het bewerken van adresboeken bijvoorbeeld geldt: mkdir dient voor 
het aanmaken van een nieuw adresboek, rmdir (‘remove directory’: verwijder 
adresboek) verwijdert een adresboek, cd (‘change directory’: wijzig adresboek) 
wijst een ander adresboek als het actieve adresboek aan en pwd (‘path working 
directory’: pad aktieve adresboek) drukt de absolute padnaam af van het lopende 
aktieve adresboek. 

Het /s-programma (‘list source’: lijst bron) drukt een lijst van namen af van 
de bestanden in het actieve adresboek. Er zijn achttien opties om aan te vragen 
dat bestandseigenschappen mee afgedrukt worden. Met de -/ optie bijvoorbeeld 
kan men een lange lijst opvragen met de bestandsnaam, eigenaar, beveiliging, 
datum en tijdstip waarop het bestand werd aangemaakt en de grootte (in bytes). 
Het cp-programma (‘copy’) maakt een nieuw bestand aan dat een kopie is van 
een bestaand bestand. Het mv-programma (‘move’) brengt een bestand over van 
de ene plaats in de adresboekboom naar een andere. In de meeste gevallen is 
hiervoor alleen maar nodig dat het bestand herbenoemd wordt, maar zo nodig 
wordt het bestand naar de nieuwe plaats gekopieerd en wordt de oude kopie 
opgeheven. Een bestand wordt opgeheven door het rm-programma (‘remove’), 
dat een unlink-systeemaanroep doet. 

Om een bestand op de terminal te bekijken kan de gebruiker cat gebruiken. 
Het cat-programma neemt een lijst van bestanden en schakelt deze aan elkaar, 
waarbij dan het resultaat naar de standaarduitvoereenheid, gewoonlijk de ter- 
minal, gekopieerd wordt. Op een snelle beeldbuis gaat het bestand mogelijk zo 
snel voorbij dat er geen tijd is om dit te lezen. Het more-programma laat van het 
bestand één scherm tegelijk zien en wacht dan tot de gebruiker een teken intypt 
voordat het verder gaat naar het volgende scherm. Het head-programma laat al- 
leen de beginregels van een bestand zien, terwijl tail de laatste paar regels laat 
zien. 

Dit zijn de basissysteemprogramma’s die veelvuldig in Unix gebruikt wor- 
den. Dan zijn er nog een aantal opmaakprogramma’s (ed, sed, emacs, vi, …), COM- 
pileerprogramma’s (C, Pascal, FORTRAN, …) en tekstformateerprogramma’s 
(troff, tex, scribe, ...). Er zijn ook programma’s voor het sorteren (sort) en verge- 
lijken (cmp, diff) van bestanden, het zoeken naar patronen (grep, awk), het sturen 
van post naar andere gebruikers (mail) en vele andere aktiviteiten. 


14.4.1 Schillen en commando’s 


Programma’s, zowel systeemprogramma’s als door de gebruiker geschreven pro- 
gramma’s, worden gewoonlijk uitgevoerd door een commandovertolker. De com- 
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mandovertolker in Unix is een gebruikersproces zoals ieder ander. Het wordt een 
schil (Engels: shell) genoemd, daar het de kern van het besturingssysteem om- 
ringt. Gebruikers kunnen hun eigen schil schrijven en er zijn in feite diverse schil- 
len die algemeen worden gebruikt. De Bourne-schil, geschreven door Steven 
Bourne, is waarschijnlijk de meest gebruikte, of althans de schil die overal ver- 
krijgbaar is. De C-schil, voor het grootste deel het werk van Bill Joy, is de popu- 
lairste schil op BSD-systemen. 

De veel voorkomende schillen hebben een commandotaal met een groten- 
deels gemeenschappelijke syntaxis. Unix is normaliter een interactief systeem. 
De schil geeft aan dat hij klaar is om een nieuw commando aan te nemen door 
een oproepteken af te drukken, waarna de gebruiker op een enkele regel een 
commando intikt. Bijvoorbeeld, in de regel 


% Is -l 


is het percentteken het gebruikelijke oproepteken van de C-schil en de /s -/ (inge- 
tikt door de gebruiker) het commando voor het uitlijsten van het adresboek. 
Commando's kunnen argumenten hebben, die de gebruiker na de comman- 
donaam op dezelfde regel intikt, met een blanke ruimte (spatie of tabulaties) 
ertussen. 

Hoewel een paar commando’s in de schillen zijn ingebouwd (zoals cd), is 
een commando gewoonlijk een uitvoerbaar binair doelbestand. Een lijst van ver- 
schillende adresboeken, het zoekpad, wordt in de schil bewaard. Voor elk com- 
mando wordt ieder adresboek in het zoekpad doorzocht op een bestand met de- 
zelfde naam. Wordt een bestand gevonden, dan wordt dit geladen en uitgevoerd. 
Het zoekpad kan worden ingesteld door de gebruiker. De adresboeken /bin en 
/usr/bin liggen bijna altijd in het zoekpad; een typisch voorbeeld van een zoek- 
pad op een BSD-systeem zou kunnen zijn: 


( . /usr/local/bin /usr/ucb /bin /usr/bin) 


Het doelbestand van het /s-commando is /bin/ls en dat van de schil zelf is 
/bin/sh (de Bourne-schil) of /bin/csh (de C-schil). 

De uitvoering van een commando vindt plaats door een fork-systeemaan- 
roep (vertak) gevolgd door een execve van het doelbestand. De schil doet dan 
gewoonlijk een wait (wacht) om zijn eigen uitvoering op te schorten tot het com- 
mando voltooid is (zie figuur 14.4). Er is een eenvoudige syntaxis (een & teken 
aan het einde van de commandoregel) om aan te geven dat de schil niet hoeft te 
wachten. Een commando dat we op deze manier uitvoeren terwijl de schil door- 
gaat met het vertolken van volgende commando's, noemen we een achtergrond- 
commando, of we zeggen dat het in de achtergrond draait. Processen waarop de 
schil wel wacht draaien, zoals dat heet, in de voorgrond. 

De C-schil in 4.2BSD-systemen biedt een voorziening die men job-besturing 
noemt (gedeeltelijk in de kern geïmplementeerd). Job-besturing zorgt ervoor dat 


528 Hoofdstuk 14 Het Unix-besturingssysteem 


proces 


schijn- 
proces 


commando |wordt uitgevoerd 


Figuur 14.4 
Een schil vertakt een subproces voor het uitvoeren van een commando 


processen van de voorgrond naar de achtergrond verplaatst kunnen worden en 
omgekeerd. Zij kunnen op verschillende condities gestopt en opnieuw gestart 
worden, zoals een achtergrond-job die wacht op invoer van de terminal van de 
gebruiker. Hierdoor kan in bijna iedere vorm van procesbesturing voorzien wor- 
den door koppelingen met vensters (Engels: windowing) of lagen (Engels: 
layering), maar hiervoor is geen speciale apparatuur nodig. 


14.4.2 Standaard-I/O 


Processen kunnen naar believen bestanden openen, maar de meeste processen 
verwachten dat drie bestanden (met bestandsbeschrijvers 0, 1 en 2) al open zijn 
wanneer zij beginnen. Deze staan bekend als standaardinvoer (0), standaarduitvoer 
(1) en standaardfout (2). Deze bestandsbeschrijvers worden overgeërfd via de 
execve (en eventueel de fork) die het proces creëerde. Alle drie zijn ze vaak open 
voor de terminal van de gebruiker. Zo kan het programma lezen wat de gebruiker 
intikt door standaardinvoer te lezen en kan het programma uitvoer naar de ter- 
minal van de gebruiker sturen door naar standaarduitvoer te schrijven. Het stan- 
daardfoutbestand is ook open voor schrijven en wordt gebruikt voor uitvoer van 
foutmeldingen; standaarduitvoer wordt gebruikt voor gewone uitvoer. De meeste 
bestanden kunnen ook een bestand (in plaats van een terminal) accepteren voor 
hun standaardinvoer en standaarduitvoer. 

De veel voorkomende schillen hebben een eenvoudige syntaxis voor het 
wijzigen van die bestanden die open zijn voor de standaard-I/O van een proces. 
Het wijzigen van een standaardbestand wordt I/O-herbestemming (Engels: I/O 
redirection) genoemd. De syntaxis voor I/O-herbestemming is aangegeven in fi- 
guur 14.5. In dit voorbeeld produceert het Is-commando een lijst van de namen 
van de bestanden in het actieve adresboek, het pr-commando formateert die lijst 
in pagina’s die geschikt zijn voor een printer en het Ipr-commando doet een spool- 
verwerking van de gefomateerde uitvoer naar een printer, zoals /dev/Ip0. 


14.4 Koppeling met de gebruiker 


% Is > bsta # bestem uitvoer van /s voor bestand bsta 
% pr < bsta > bstb # invoer van bsta en uitvoer naar bstb 
% Ipr < bstb # invoer van bstb 

Figuur 14.5 


Standaardherbestemming van I/O 


14.4.3 Pijplijnen, filters en schil-scripten 


Het voorbeeld in drie stappen van figuur 14.5 had ook gedaan kunnen worden 
met behulp van het ene commando: 


% Is | pr | lpr 


Iedere verticale deelstreep vertelt de schil dat de uitvoer van het voorgaande com- 
mando doorgegeven moet worden als invoer voor het volgende commando. Een 
pijp wordt gebruikt om de gegevens van het ene naar het andere proces over te 
brengen. Het ene proces schrijft dan in het ene uiteinde van de pijp en een ander 
proces leest uit het andere uiteinde. In het voorbeeld wordt het schrijfuiteinde 
van de pijp zo door de schil opgezet dat het de standaarduitvoer van /s is en het 
leesuiteinde van de pijp is dan de standaardinvoer van pr; er is een andere pijp 
tussen pr en lpr. 

Een commando zoals pr dat zijn standaardinvoer doorgeeft aan zijn stan- 
daarduitvoer, waarbij enige bewerking plaatsvindt, heet een filter. Vele Unix- 
commando’s kunnen als filters gebruikt worden. Men kan gecompliceerde func- 
ties opbouwen uit pijplijnen van veel voorkomende commando's. Ook veel voor- 
komende functies, zoals het formateren van uitvoer, hoeven niet als onderdeel 
van vele commando’s ingebouwd te worden, omdat de uitvoer van bijna elk pro- 
gramma via pr (of een ander geschikt filter) door een pijp kan worden gestuurd. 

De beide veel voorkomende Unix-schillen zijn ook programmeertalen, met 
schilvariabelen en de gebruikelijke besturingsconstructies van hogere program- 
meertalen (lussen, voorwaardelijke opdrachten). De uitvoering van een comman- 
do is analoog aan een subroutine-aanroep. Een bestand van schilcommando’s, 
een schil-script, kan worden uitgevoerd zoals elk ander commando, waarbij de 
juiste schil automatisch wordt aangeroepen om het script te lezen. Op deze wijze 
kan van schilprogrammering gebruik worden gemaakt om gemakkelijk gewone 
programma’s te combineren tot zeer ingewikkelde toepassingen, zonder dat er 
een programma in een conventionele taal geschreven hoeft te worden. 

Men denkt gewoonlijk dat wat de gebruiker er van de buitenkant van ziet 
de definitie van Unix is; maar dat is nu juist de definitie die het gemakkelijkst 
gewijzigd kan worden. Het schrijven van een nieuwe schil met een geheel verschil- 
lende syntaxis en semantiek zou het beeld dat de gebruiker van Unix heeft in 
grote mate wijzigen, terwijl de kern, of zelfs de koppeling met de programmeur, 
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geen verandering zou ondergaan. Er wordt bijvoorbeeld in diverse locaties ge- 
werkt aan het ontwikkelen van door menu’s bestuurde en iconische (dat wil zeg- 
gen: met afbeeldingen werkende) koppelingen voor Unix. Het hart van Unix is 
natuurlijk zijn kern. In de resterende paragrafen van dit hoofdstuk onderzoeken 
we de kern en zijn gegevensstructuren en werking. We beginnen met het bestands- 
systeem. 


14.5 Bestandssysteem 


Het Unix-bestandssysteem ondersteunt twee hoofdbegrippen: bestanden en 
adresboeken. Adresboeken zijn in feite gewoon bestanden met een speciaal for- 
maat, zodat de representatie van een bestand het basisconcept van Unix is. 


14.5.1 Blokken en fragmenten 


Het grootste gedeelte van het bestandssysteem wordt gevormd door gegevensblok- 
ken, die alles bevatten wat de gebruikers in hun bestanden hebben gezet. Laten 
we eens zien hoe deze gegevensblokken op schijf zijn opgeslagen. 

De apparatuur kent een schijfsector die gewoonlijk uit 512 bytes bestaat. 
Een blokgrootte van meer dan 512 bytes is wenselijk uit het oogpunt van snel- 
heid. Daar Unix-bestandssystemen echter gewoonlijk een zeer groot aantal kleine 
bestanden bevatten, zouden blokken die véél groter zijn een overmaat aan interne 
fragmentatie veroorzaken. Daarom bleef het vroegere 4.1BSD-bestandssysteem 
beperkt tot een blok van 1024 bytes. 

De oplossing in 4.2BSD is het gebruiken van twee blokgrootten: alle blok- 
ken van een bestand hebben een grote blokgrootte (bijvoorbeeld 8192), behalve 
het laatste. De grootte van het laatste blok is een geschikt veelvoud van een 
kleinere fragmentgrootte (bijvoorbeeld 1024) om de rest van het bestand te kun- 
nen bergen. Zo zou een bestand van 18000 bytes twee blokken kunnen hebben 
van 8192 bytes en één fragment van 2048 bytes (dat niet geheel vol zou zijn). 

De blok- en fragmentgrootten worden tijdens het creëren van het bestands- 
systeem ingesteld in overeenstemming met het geplande gebruik van het be- 
standssysteem: als men veel kleine bestanden verwacht moet de fragmentgrootte 
klein zijn; als herhaald overbrengen van grote bestanden wordt verwacht, moet 
de basisblokgrootte groot zijn. Als gevolg van details in de implementatie is de 
blok/segment-verhouding maximaal 8/1, met een minimumblokgrootte van 
4096, zodat de keuze gewoonlijk valt op 4096/512 in het eerste en 8192/1024 in 
het tweede geval. 

Stel dat gegevens naar een bestand worden geschreven door overbrenging 
in stukken van 1024 bytes, terwijl de blok- en fragmentgrootten van het bestands- 
systeem respectievelijk 4096 en 512 bytes zijn. Het bestandssysteem zal dan een 
fragment van 1024 bytes toewijzen dat de gegevens van de eerste overbrenging 
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moet bevatten. De volgende overbrenging zal de toewijzing van een nieuw frag- 
ment, van 2048 bytes, tot gevolg hebben. De gegevens van het oorspronkelijke 
fragment moeten in dit nieuwe fragment worden gekopieerd, waarna de over- 
brenging volgt van de tweede 1024 bytes. De toewijzingsroutines proberen ruimte 
op de schijf te vinden die onmiddellijk volgt op het bestaande fragment, zodat 
kopiëren niet nodig is, maar als dit niet mogelijk is kunnen er maximaal zeven 
kopieën nodig zijn voordat het fragment een blok wordt. Er zijn voorzieningen 
getroffen in de vorm van programma’s die de blokgrootte voor een bestand kun- 
nen ontdekken, zodat overbrengingen van die grootte kunnen plaatsvinden, om 
herhaald kopiëren van fragmenten te voorkomen. 


14.5.2 I-knooppunten 


Een bestand wordt geprepresenteerd door een i-knooppunt (index-knooppunt; 
Engels: ‘index node’ of ‘i-node’, tegenwoordig ’inode’). Een inode is een record, 
waarin het grootste gedeelte van de informatie over een bestand op schijf is opge- 
slagen. 

Het i-knooppunt bevat de gebruikers- en groepsidentificatiesymbolen van 
het bestand, het tijdstip waarop het voor het laatst is gewijzigd en het tijdstip 
waarop het voor het laatst benaderd werd, een telling van het aantal harde 
schakels (adresboekingangen) en het type van het bestand (gewoon bestand, 
adresboek, symbolische schakel, tekengeoriëntieerd randapparaat, blokgeoriën- 
teerd randapparaat of ’socket’). Daarnaast bevat het i-knoopppunt vijftien wij- 
zers naar de schijfblokken die de gegevensbytes van het bestand bevatten. De 
eerste twaalf wijzers wijzen naar directe blokken; dat wil zeggen, zij bevatten 
rechtstreeks adressen van blokken met gegevens van het bestand. Op deze manier 
kan onmiddellijk naar de gegevens van kleine bestanden (niet meer dan twaalf 
blokken) worden verwezen, omdat een kopie van het i-knooppunt in het interne 
geheugen bewaard wordt zolang een bestand open is. Is de blokgrootte 4096 
bytes, dan kan direct vanuit het i-knooppunt tot hooguit 48K bytes gegevens 
toegang worden verkregen. 

De volgende drie wijzers in het i-knooppunt wijzen naar indirecte blokken. 
Als het bestand groot genoeg is voor het gebruik van indirecte blokken, hebben 
deze elk de maximale blokgrootte; de fragmentgrootte is alleen van toepassing 
op gegevensblokken. De eerste indirecte wijzer is het adres van een enkelvoudig 
indirect blok. Het enkelvoudige indirecte blok is een indexblok, waarin geen gege- 
vens staan maar de adressen van blokken die wel gegevens bevatten. Vervolgens 
is er een wijzer naar een dubbel indirect blok: het adres van een blok met de 
adressen van blokken die wijzers naar de werkelijke gegevensblokken bevatten. 
Tenslotte zou de laatste wijzer het adres van een drievoudig indirect blok kunnen 
bevatten, ware het niet dat daaraan geen behoefte bestaat. De minimumblok- 
grootte voor een bestandssysteem in 4.2BSD is 4096 bytes, zodat zelfs bestanden 
met 232 bytes alleen dubbele, geen drievoudige, indirecte adressering zullen ge- 
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bruiken. Omdat elke blokwijzer vier bytes in beslag neemt wil dat zeggen dat we 
49.152 bytes kunnen adresseren in directe blokken, 4.194.304 bytes met enkelvou- 
dige indirecte adressering en 4.294.967.296 bytes met behulp van dubbele indirec- 
te adressering. Hiermee komen we op een totaal van 4.299.210.752 bytes, wat al 
meer is dan 2% bytes. Het getal 232 is van belang omdat de afstand vanaf het 
begin in de bestandstructuur in een woord van 32 bits wordt bewaard. Daarom 
kunnen bestanden niet groter zijn dan 232 bytes. Voor de meeste doeleinden is 
vier gigabytes genoeg. 


14.5.3 Adresboeken 


Er is geen onderscheid tussen gewone bestanden en adresboeken op dit imple- 
mentatieniveau; de inhoud van adresboeken wordt in gegevensblokken bewaard 
en adresboeken worden op dezelfde manier door een i-knooppunt gerepresen- 
teerd als gewone bestanden. Alleen door het type-veld in het i-knooppunt zijn 
gewone bestanden en adresboeken van elkaar te onderscheiden. Van gewone be- 
standen wordt aangenomen dat ze geen interne structuur hebben, terwijl adres- 
boeken wel een specifieke structuur bezitten. In Versie 7 waren bestandsnamen 
beperkt tot veertien tekens, zodat adresboeken een lijst vormden met ingangen 
van zestien bytes: twee bytes voor een i-nummer en veertien bytes voor een be- 
standsnaam. 

In 4.2BSD hebben bestandsnamen een variabele lengte van maximaal 255 
bytes en dus hebben de adresboekingangen ook een variabele lengte. Elke ingang 
bevat eerst de lengte van de ingang, dan de bestandsnaam en zijn i-nummer. Het 
feit dat de ingang een variabele lengte heeft maakt het adresboekbeheer en de 
zoekroutines moeilijker, maar betekent een grote verbetering in deze zin dat ge- 
bruikers zinvolle namen voor hun bestanden en adresboeken kunnen kiezen, zon- 
der dat er in de praktijk een grens aan de naamlengte gesteld hoeft te worden. 

De eerste twee namen in elk adresboek zijn °: en ’..’. Nieuwe adresboekin- 
gangen worden aan het adresboek toegevoegd in de eerst beschikbare ruimte, in 
het algemeen na bestaande bestanden. Er wordt daarbij van een lineaire zoekme- 
thode gebruik gemaakt. 

De gebruiker verwijst naar een bestand met behulp van een padnaam, ter- 
wijl het bestandssysteem het i-knooppunt als zijn definitie van een bestand ge- 
bruikt. Daarom moet de kern de padnaam van de gebruiker vertalen naar een 
i-knooppunt. Voor deze vertaling wordt van de adresboeken gebruik gemaakt. 

Ten eerste wordt er een beginadresboek vastgesteld. Als het eerste teken 
van de padnaam ’/’ is, is het beginadresboek het worteladresboek. Als de pad- 
naam met een ander teken dan de schuine deelstreep begint, is het beginadres- 
boek het actieve adresboek van het huidige proces. In het beginadresboek wordt 
gecontroleerd of het bestand bestaat, of het bestandstype juist is en of het proces 
toegangsrecht heeft tot dit bestand; zo nodig wordt een foutcode teruggegeven. 
Het i-knooppunt van het beginadresboek is altijd beschikbaar. 
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Het volgende element van de padnaam, tot de volgende ’/’ of het eind van 
de padnaam, is een bestandsnaam. Het beginadresboek wordt op deze naam 
doorzocht en er wordt een foutcode teruggegeven als deze niet wordt gevonden. 
Als er nog een element in de padnaam voorkomt, moet het actieve i-knooppunt 
naar een adresboek verwijzen; zo niet, dan wordt een foutcode teruggegeven of 
wordt de toegang geweigerd. Dit adresboek wordt op dezelfde manier doorzocht 
als het vorige. Dit proces gaat door tot het eind van de padnaam is bereikt en 
het gewenste i-knooppunt is teruggegeven. 

Harde schakels zijn gewoon adresboekingangen zoals elke andere adres- 
boekingang. Symbolische schakels worden voor het grootste deel behandeld door 
opnieuw te beginnen met zoeken op grond van de padnaam die uit de inhoud 
van de symbolische schakel is gehaald. Men voorkomt oneindige lussen door het 
aantal symbolische schakels dat tijdens een zoekproces op de padnaam is ont- 
moet te tellen en een foutcode terug te geven wanneer een grens (8) wordt over- 
schreden. 

Voor bestanden die niet op schijf staan (zoals randapparatuur bijvoorbeeld) 
zijn geen gegevensblokken op schijf toegewezen. De kern neemt nota van de be- 
standstypen (zoals aangegeven in het i-knooppunt) en roept dan de juiste stuur- 
code binnen de kern aan om de I/O daarvoor te behandelen. 

Is het i-knooppunt eenmaal gevonden, bijvoorbeeld door de open-systeem- 
aanroep, dan wordt een bestandsstructuur toegewezen om naar het i-knooppunt 
te wijzen. De bestandsbeschrijver die aan de gebruiker wordt gegeven verwijst 
naar deze bestandsstructuur. 


14.5.4 Via een bestandsbeschrijver naar een i-knooppunt 


Systeemaanroepen die naar open bestanden verwijzen geven het bestand aan 
door een bestandsbeschrijver als argument mee te geven. De bestandsbeschrijver 
wordt door de kern gebruikt als index in een tabel van open bestanden voor het 
huidige proces. Iedere ingang van de tabel bevat een wijzer naar een bestands- 
structuur. Deze bestandsstructuur wijst op zijn beurt naar het i-knooppunt (zie 
figuur 14.6). De read- en write-systeemaanroepen accepteren als argument geen 
positie in het bestand. In plaats daarvan houdt de kern een relatieve bestandsposi- 
tie (Engels: file offset) bij, die na elke read- of write-aanroep met het juiste aantal 
wordt opgehoogd in overeenstemming met de hoeveelheid gegevens die in feite 
werden overgebracht. De relatieve positie kan direct worden ingesteld met behulp 
van de /seek-systeemaanroep. Zou de bestandsbeschrijver als index gebruikt wor- 
den in een rij van bestandswijzers, dan had deze relatieve positie in het i-knoop- 
punt bewaard moeten worden. Aangezien meer dan één proces hetzelfde bestand 
kan openen en elk van deze processen zijn eigen relatieve positie voor het bestand 
nodig heeft, is het niet juist de relatieve positie in het i-knooppunt te bewaren. 
Daarom wordt hiervoor de bestandsstructuur gebruikt. 

Bestandsstructuren worden na een vertak door het kind geërfd, zodat het 
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Besturingsblokken van het bestandssysteem 


mogelijk is dat verschillende processen dezelfde relatieve positie in een bestand 
hebben. 

De i-knooppuntstructuur waarnaar de bestandsstructuur verwijst is een 
kopie in het interne geheugen van het i-knooppunt op de schijf en wordt toegewe- 
zen uit een tabel met een vaste lengte. Het i-knooppunt in het interne geheugen 
heeft een paar extra velden, zoals het aantal verwijzingen door bestandsstruc- 
turen. De bestandsstructuur heeft een soortgelijke teller voor het aantal bestands- 
beschrijvers dat ernaar verwijst. 


14.5.5 Schijfstructuren 


Het bestandssysteem dat de gebruiker ziet wordt ondersteund door gegevens op 
een randapparaat voor massale opslag van gegevens, meestal een schijf. De ge- 
bruiker heeft gewoonlijk slechts weet van één bestandssysteem, maar dit ene logi- 
sche bestandssysteem kan in werkelijkheid wel uit verschillende fysieke bestands- 
systemen bestaan, elk op een ander randapparaat. Omdat de kenmerken van de 
verschillende soorten randapparatuur ook verschillen, bepaalt elk type randappa- 
ratuur zijn eigen fysieke bestandssysteem. Feitelijk is het in het algemeen wense- 
lijk grote fysieke randapparaten, zoals schijven, op te delen in meerdere logische 
randapparaten. Elk logisch randapparaat bepaalt een fysiek bestandssysteem. Fi- 
guur 14.7 laat zien hoe een adresboekstructuur is opgedeeld in bestandssystemen, 
die worden vertaald naar logische randapparaten, die zelf weer delen zijn van 
fysieke randapparatuur. 

Het onderverdelen (‘partitioneren’) van een fysiek randapparaat in meer- 
dere bestandssystemen heeft verschillende voordelen. Verschillende bestandssys- 
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Figuur 14.7 
Het vertalen van een logisch bestandssysteem naar de fysieke randapparatuur 


temen kunnen verschillende soorten gebruik ondersteunen. Hoewel de meeste 
partities voor het bestandssysteem gebruikt zullen worden, is er ten minste één 
nodig als gebied voor programmaverwisseling voor de programmatuur ten behoe- 
ve van het virtueel-geheugenbeheer. De betrouwbaarheid wordt groter, aangezien 
door de programmatuur veroorzaakte schade in het algemeen tot slechts één be- 
standssysteem wordt beperkt. De efficiëntie kan worden verhoogd door de pa- 
rameters van het bestandssysteem voor elke partitie (zoals de blok- en fragment- 
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grootte) anders in te stellen. Ook kan men met afzonderlijke bestandssystemen 
voorkomen dat één programma alle beschikbare ruimte voor een groot bestand 
gebruikt, omdat bestanden niet over verschillende bestandssystemen verdeeld 
kunnen worden. 

Het werkelijke aantal bestandssystemen op een aandrijfeenheid verschilt 
naar gelang van de grootte van de schijf en het doel van het computersysteem 
als geheel. Eén bestandssysteem, het wortelbestandssysteem is altijd beschikbaar. 
Andere kunnen worden gemonteerd, dat wil zeggen, kunnen worden geïntegreerd 
in de adresboekhiérarchie van het wortelbestandssysteem. 

Er is een bit in de i-knooppuntstructuur om aan te geven dat een bestands- 
systeem op het i-knooppunt gemonteerd is. Een verwijzing naar dit bestand geeft 
aanleiding tot een zoekproces door de montagetabel om het apparaatgetal van het 
gemonteerde randapparaat te vinden. Het apparaatgetal wordt dan gebruikt om 
het i-knooppunt van het worteladresboek van het gemonteerde bestandssysteem 
te vinden, waarna dat i-knooppunt wordt gebruikt. Omgekeerd moet, als een 
element van een padnaam ’..’ is en het adresboek dat doorzocht wordt het wor- 
teladresboek van een gemonteerd bestandssysteem is, de montagetabel worden 
doorzocht om het i-knooppunt te vinden waarop het gemonteerd is, en wordt dat 
i-knooppunt gebruikt. 

Elk bestandssysteem is een afzonderlijke systeemfaciliteit die een groep be- 
standen representeert. De eerste sector op het logische randapparaat is het start- 
blok, dat een primaire zelfstartroutine bevat die kan worden gebruikt om een 
secundaire zelfstartroutine aan te roepen die in de volgende 7,5K bytes ligt opge- 
slagen. Het superblok bevat statische parameters van het bestandssysteem, de 
blok- en fragmentgrootten van de gegevensblokken en passende parameters voor 
het beïnvloeden van het toewijzingsbeleid. 


14.5.6 Implementaties 


De koppeling tussen de gebruiker en het bestandssysteem is eenvoudig en goed 
gedefinieerd. Dit heeft het mogelijk gemaakt dat de implementatie van het 
bestandssysteem werd gewijzigd zonder dat de gebruiker daar noemenswaard 
last van had. Het bestandssysteem werd gewijzigd tussen Versie 6 en Versie 7, en 
nogmaals tussen Versie 7 en 4BSD. Voor Versie 7 werd de grootte van de 
i-knooppunten verdubbeld, nam de maximumgrootte van bestanden en bestands- 
systemen toe, en kwamer er wijzigingen in de behandeling van de vrije-ruimtelijst 
en van de superblokinformatie. Toen veranderde ook seek (met een relatieve posi- 
tie van 16 bits) in /seek (met een relatieve positie van 32 bits) om het mogelijk te 
maken dat de relatieve posities correct gespecificeerd werden in de bestanden 
die groter waren dan voorheen toegestaan was, maar waren er weinig andere 
wijzigingen zichtbaar buiten de kern. 

In 4.0BSD nam de grootte van blokken die in het bestandssysteem werden 
gebruikt toe van 512 bytes tot 1024 bytes. Hoewel dit de interne fragmentatie op 
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de schijf deed toenemen, werd de doorvoercapaciteit verdubbeld, hoofdzakelijk 
wegens de toegankelijkheid van een grotere hoeveelheid gegevens bij iedere over- 
brenging van of naar schijf. Dit idee werd later, tezamen met een aantal andere 
ideeën, stuurcode voor de randapparatuur en andere programma’s, overgenomen 
in Systeem V. 


14.5.7 Indeling en toewijzingsbeleid 


De kern maakt gebruik van een logisch-randapparaatnummer/ i-knooppuntnummer 
paar om een bestand te identificeren. Het logisch-randapparaatnummer bepaalt 
welk bestandssysteem hierbij betrokken is. De i-knooppunten in het bestandssys- 
teem zijn op volgorde genummerd. In het bestandssysteem van Versie 7 bevinden 
de i-knooppunten zich alle in een reeks (array) die onmiddellijk op een enkel 
superblok volgt aan het begin van het logisch randapparaat, waarbij de gegevens- 
blokken na de i-knooppunten komen. Het i-nummer is in feite alleen maar een 
index in deze reeks. 

Bij het bestandssysteem van Versie 7 kan een blok van een bestand zich op 
een willekeurige plaats op de schijf bevinden tussen het einde van de i-knoop- 
puntreeks en het einde van het bestandssysteem. Vrije blokken worden in een 
geschakelde lijst in het superblok bewaard. Blokken worden naar het begin van 
de vrije-ruimtelijst geduwd en van het begin af gebruikt naar gelang dit nodig is 
voor nieuwe bestanden of voor het uitbreiden van bestaande bestanden. Op deze 
manier kunnen de blokken van een bestand willekeurig ver van zowel het 
i-knooppunt als van elkaar verwijderd zijn. Bovendien, hoe meer een dergelijk 
bestandssysteem wordt gebruikt, hoe groter de desorganisatie van de blokken in 
een bestand wordt. Dit proces kan alleen worden omgekeerd door het gehele 
bestandssysteem opnieuw te initialiseren en te herstellen, wat niet bepaald ge- 
makkelijk is. 

Een andere moeilijkheid is de betrouwbaarheid van het bestandssysteem. 
Om aan snelheid te winnen wordt ieder superblok van elk gemonteerd bestands- 
systeem in het geheugen bewaard. Dit maakt het mogelijk dat de kern snel toe- 
gang heeft tot elk superblok, speciaal voor het gebruik van de vrije-ruimtelijst. 
Elke 30 seconden wordt het superblok naar de schijf weggeschreven, om de kopie 
in het geheugen met die op de schijf synchroon te laten blijven (de sync-systeem- 
aanroep). Het is echter geen zeldzaamheid dat, wanneer het systeem als gevolg 
van systeemfouten of storingen in de apparatuur stukloopt, het superblok in het 
geheugen vernietigd wordt. De vrije-ruimtelijst gaat dan verloren en moet op- 
nieuw worden geconstrueerd door middel van een tijdrovend onderzoek van alle 
blokken van het bestandssysteem. 

De implementatie van het bestandssysteem in 4.2BSD verschilt radicaal 
van die in Versie 7. Deze herimplementatie vond hoofdzakelijk plaats met het 
oog op efficiëntie en robuustheid; de meeste van die wijzigingen zijn buiten de 
kern niet zichtbaar. Gelijktijdig werden enkele andere wijzigingen geïntrodu- 
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ceerd, zoals symbolische schakels en lange bestandsnamen (tot 255 tekens), die 
zichtbaar zijn zowel op het niveau van de systeemaanroep als op dat van de 
gebruiker. De meeste wijzigingen die voor deze voorzieningen vereist waren be- 
vonden zich evenwel niet in de kern, maar in de programma’s die van deze voor- 
zieningen gebruik maken. 

Met name de toewijzing van ruimte is anders. Het belangrijkste nieuwe idee 
in 4.2BSD is de cilindergroep. De cilindergroep werd ingevoerd om het mogelijk 
te maken de blokken in een bestand op één plaats bijeen te houden. Elke cilinder- 
groep neemt een of meer aaneensluitende cilinders van de schijf in beslag, zodat 
toegangen binnen de cilindergroep een minimum aan bewegingen van de lees/ 
schrijfkop vereisen. Elke cilindergroep heeft een superblok, een cilinderblok, een 
reeks i-knooppunten en een aantal gegevensblokken (zie figuur 14.8). 

Het superblok is in iedere cilindergroep identiek, zodat het in geval van 
schijfbeschadiging uit elk daarvan kan worden hersteld. Het cilinderblok bevat 
de dynamische parameters van de cilindergroep in kwestie. Dit zijn onder andere 
een bittabel van vrije gegevensblokken en -fragmenten en een bittabel van vrije 
i-knooppunten. Ook worden hier statistieken bijgehouden van de recente voort- 
gang van de toewijzingsstrategieën. 

De kopinformatie in een cilindergroep (het superblok, het cilinderblok en 
de i-knooppunten) staat niet altijd aan het begin van de cilindergroep. Als dat 
zo was, zou de kopinformatie voor elke cilinder zich op hetzelfde schijfoppervlak 
kunnen bevinden; één beschadiging door contact met de lees/schrijfkop zou al 
deze informatie teniet kunnen doen. Daarom heeft iedere cilindergroep zijn 
kopinformatie op een andere afstand van het begin van de groep. 

Het komt veel voor dat het adresboekuitlijst-commando ls alle i-knooppun- 
ten van elk bestand in een adresboek leest; hierdoor is het wenselijk dat al zulke 
i-knooppunten dichtbij elkaar staan. Om deze reden wordt het i-knooppunt voor 
een bestand gewoonlijk uit dezelfde cilindergroep toegewezen als het i-knoop- 
punt van zijn ouderadresboek. Niet alles kan echter bijeen gezet worden, zodat 


gegevensblokken 


Figuur 14.8 
Cilindergroep in 4.2BSD 
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een i-knooppunt voor een nieuw adresboek in een andere cilindergroep geplaatst 
wordt dan die van zijn ouderadresboek. De cilindergroep die voor een i-knoop- 
punt van zo’n nieuw adresboek wordt gekozen is die met het grootste aantal 
ongebruikte i-knooppunten. 

Om het aantal zoekbewerkingen van de lees/schrijfkop bij het toegang krij- 
gen tot de gegevensblokken te verminderen, worden zoveel mogelijk blokken van 
dezelfde cilindergroep toegewezen. Daar het niet kan worden toegestaan dat één 
bestand alle blokken in een cilindergroep in beslag neemt, worden voor een be- 
stand dat een zekere grootte (zoals 32K bytes) overschrijdt de resterende blokken 
uit een nieuwe cilindergroep toegewezen, waarbij de nieuwe groep gekozen wordt 
uit die groepen die een vrije ruimte hebben die groter is dan het gemiddelde. 
Groeit het bestand nog verder, dan vindt (bij iedere megabyte) de toewijzing 
opnieuw uit een andere cilindergroep plaats. Op deze manier komen alle blokken 
van een klein bestand waarschijnlijk in dezelfde cilindergroep voor en wordt dus 
het aantal zoekbewerkingen over een grote lengte bij de toegang tot een groot 
bestand klein gehouden. 

Er zijn twee niveaus waarop routines voor de toewijzing van schijfblokken 
opereren. De routines voor het globale beleid kiezen een gewenst schijfblok uit 
in overeenstemming met de hierboven gegeven overwegingen. De routines voor 
het lokale beleid gebruiken de specifieke informatie die in de cilinderblokken is 
vastgelegd voor het kiezen van een blok dat dichtbij het gevraagde blok ligt. Als 
het gevraagde blok niet in gebruik is, wordt het vrijgegeven voor gebruik. Anders 
wordt het blok dat in rondgaande zin het dichtst erbij in dezelfde cilinder ligt 
vrijgegeven, of een blok in een andere cilinder maar in dezelfde cilindergroep. 
Als er geen blokken in de cilindergroep over zijn, wordt er een nieuwe kwadrati- 
sche hash-operatie op de andere cilindergroepen uitgevoerd om een blok te vin- 
den. Als dat mislukt wordt er een volledige zoekbewerking uitgevoerd. Is er ge- 
noeg vrije ruimte (gewoonlijk 10%) in het bestandssysteem over, dan worden de 
blokken gewoonlijk gevonden waar deze gewenst waren; dan zijn de kwadrati- 
sche nieuwe hash-operatie en de volledige zoekbewerking niet nodig en neemt 
het prestatievermogen van het bestandssysteem niet met het gebruik af. 

Het 4.2BSD-systeem is in staat 30% of meer van de bandbreedte van de 
gemiddelde schijf te gebruiken, in tegenstelling tot ongeveer 3% of minder voor 
het bestandssysteem van Versie 7. 
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Een belangrijk ontwerpprobleem voor besturingssystemen is de representatie van 
processen. Eén aanmerkelijk verschil tussen Unix en vele andere systemen is het 
gemak waarmee in Unix meerdere processen gecreëerd en gehanteerd kunnen 
worden. Deze processen worden in Unix gerepresenteerd door diverse besturings- 
blokken. Er zijn geen besturingsblokken van het systeem toegankelijk in de vir- 
tuele adresruimte van een proces in gebruikersfase; besturingsblokken die met 
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een proces verbonden zijn worden opgeslagen in de kern. De informatie in deze 
besturingsblokken wordt door de kern gebruikt voor procesbesturing en CVE- 
werkindeling. 


14.6.1 Procesbesturingsblokken 


De fundamenteelste gegevensstructuur die met een proces verbonden is, is de 
processtructuur. Een processtructuur bevat alles wat het systeem dient te weten 
over een proces dat bij programmaverwisseling uit het interne geheugen gezet is, 
zoals zijn unieke procesidentificatienummer, werkindelingsinformatie (zoals de 
prioriteit van het proces) en wijzers naar andere besturingsblokken. Er is een 
reeks processtructuren, waarvan de lengte wordt gedefinieerd op het tijdstip dat 
de kern wordt gebouwd. De processtructuren van processen die gereed zijn om 
te worden uitgevoerd worden aaneengeschakeld bewaard door het werkindelings- 
programma in een dubbel aaneengeschakelde lijst (de gereed-wachtrij). Er zijn 
wijzers van elke processtructuur naar de ouder van dat proces, zijn jongste in 
leven zijnde kind en diverse andere familieleden die van belang zijn, zoals een 
lijst van processen die gemeenschappelijk van dezelfde programmacode (-tekst) 
gebruik maken. 

De virtuele adresruimte van een proces in gebruikersfase wordt onderver- 
deeld in tekst (programmacode), gegevens en stapelsegmenten. De gegevens en 
stapelsegmenten bevinden zich altijd in dezelfde adresruimte, maar deze kunnen 
afzonderlijk groeien, en wel gewoonlijk in tegengestelde richting: meestal groeit 
de stapel in de richting van de lager gelegen geheugenplaatsen, terwijl het ge- 
gevensgebied vanuit het lager gelegen geheugengedeelte naar de stapel ‘omhoog - 
groeit. Het tekstsegment bevindt zich soms (zoals op een PDP-11 met een afzon- 
derlijke instructie- en gegevensruimte) in een andere ruimte dan die van de gege- 
vens en de stapel. Het tekstsegment is meestal alleen-uitleesbaar (read-only). 

Elk proces met tekst voor gemeenschappelijk gebruik (bijna alle processen 
onder 4.2BSD) heeft een wijzer die van de processtructuur naar een tekststructuur 
wijst. De tekststructuur houdt bij hoeveel processen het tekstsegment in gebruik 
hebben, hij houdt een wijzer in een lijst van hun processtructuren bij, en hij 
registreert waar de paginatabel voor het tekstsegment op de schijf gevonden kan 
worden wanneer dit uit het interne geheugen gezet is. De tekststructuur zelf ver- 
blijft altijd in het hoofdgeheugen: een reeks van zulke structuren wordt toegewe- 
zen op het tijdstip dat de kern wordt gebouwd. De tekst, gegevens en stapelseg- 
menten kunnen uit het interne geheugen gezet zijn. Wanneer de segmenten in het 
interne geheugen worden teruggebracht, worden ze in pagina’s verdeeld. 

De paginatabellen leggen informatie vast over de vertaling van het virtuele 
naar het fysieke geheugen van het proces. De processtructuur bevat wijzers naar 
de paginatabel, die gebruikt worden wanneer het proces in het interne geheugen 
verblijft, of het adres van het proces op het randapparaat voor de programmaver- 
wisseling wanneer het uit het geheugen gezet is. Er is geen speciale afzonderlijke 
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paginatabel voor een tekstsegment dat gemeenschappelijk gebruikt wordt; elk 
proces dat dit gebruikt heeft ingangen voor zijn pagina’s in de paginatabel van 
het proces. 

Informatie over het proces die alleen nodig is wanneer het proces in het 
hoofdgeheugen verblijft (dat wil zeggen dat het niet als gevolg van programma- 
verwisseling uit het geheugen gezet is), wordt bewaard in de gebruikersstructuur 
(of g-structuur; Engels: u(ser) structure, vaak ook u(ser)-area) in plaats van in de 
processtructuur. De g-structuur wordt vertaald naar virtuele gegevensruimte in 
de kern. Een kopie van het VAX-procesbesturingsblok wordt hier bewaard om 
de algemene registers van het proces, de stapelwijzer, de programmateller en de 
basisregisters van de paginatabel veilig op te bergen wanneer het proces niet in 
uitvoering is. Er is ruimte voor het bewaren van parameters en retourwaarden bij 
systeemaanroepen. Alle gebruikers- en groepsidentificatienummers die met het 
proces verbonden zijn (niet alleen het identificatienummer van de effectieve ge- 
bruiker dat in de processtructuur bewaard wordt) worden hier bewaard. Signalen, 
tijdregisters en quota hebben hier hun gegevensstructuren. Van duidelijker belang 
voor de gewone gebruiker is dat het actieve adresboek en de tabel van open 
bestanden in de gebruikersstructuur worden bijgehouden. 

Elk proces heeft zowel een gebruikers- als een systeemfase. Het meeste ge- 
wone werk wordt gedaan in de gebruikersfase, maar wanneer er een systeemaan- 
roep wordt gedaan, is het in de systeemfase dat het inhoudelijke werk van de 
systeemaanroep gedaan wordt. De systeemfase en de gebruikersfase van een pro- 
ces zijn nooit tegelijkertijd in uitvoering. De systeemfase heeft een andere stapel 
dan de gebruikersfase. De kernstapel voor het proces volgt onmiddellijk op de 
gebruikersstructuur: de kernstapel en de gebruikersstructuur samen vormen het 
systeem-gegevenssegment voor het proces. 

In figuur 14.9 kunt u zien hoe de processtructuur wordt gebruikt om de 
verschillende delen van een proces te vinden. 

De fork-systeemaanroep (vertak) wijst een nieuwe processtructuur (met een 
nieuw procesidentificatienummer) toe aan het kindproces en kopieert de gebrui- 
kerstructuur. Gewoonlijk is er geen nieuwe tekststructuur nodig, aangezien de 
processen hun tekst gemeenschappelijk gebruiken; alleen worden de juiste tellers 
en lijsten bijgewerkt. Er wordt een nieuwe paginatabel geconstrueerd en nieuw 
hoofdgeheugen wordt toegewezen voor de gegevens- en stapelsegmenten van het 
kindproces. Het kopiëren van de gebruikersstructuur laat open-bestandsbeschrij- 
vers, gebruikers- en groepsidentificatienummers, signaalbehandeling en de mees- 
te soortgelijke eigenschappen van een proces intact. 

De vfork-systeemaanroep kopieert niet de gegevens en de stapel naar het 
nieuwe proces, maar in plaats daarvan maakt het nieuwe proces gewoon gebruik 
van de paginatabel van het oude proces. Er worden nog wel een nieuwe gebrui- 
kersstructuur en een nieuwe processtructuur gecreëerd. Het komt veel voor dat 
een schil deze systeemaanroep gebruikt voor de uitvoering van een opdracht en 
het wachten op de voltooiing ervan. Het ouderproces maakt gebruik van vfork 
om het kindproces voort te brengen. Daar het kindproces onmiddellijk een execve 
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Figuur 14.9 
Componenten van de CVE-werkindeling 


wenst te gebruiken om zijn virtuele adresruimte volledig te veranderen, is het 

niet noodzakelijk dat er een volledige kopie van het ouderproces wordt gemaakt. 

Gegevensstructuren, zoals die welke nodig zijn voor pijpbewerkingen, kunnen in 

registers bewaard worden tussen de vfork en de execve. Bestanden kunnen in het 

ene proces worden gesloten zonder dat dit van invloed is op het andere, omdat 

de betrokken gegevensstructuren van de kern afhankelijk zijn van de gebruikers- 

structuur, die niet gemeenschappelijk wordt gebruikt. De ouder gebruikt wait 
(wacht) om zijn eigen bewerking op te schorten tot het kind eindigt, zodat de 
ouder geen geheugen zal wijzigen dat het kind nodig heeft. 

Wanneer het ouderproces groot is, kan vfork aanzienlijk veel CVE-tijd in 
het systeem besparen. Het is echter een tamelijk gevaarlijke systeemaanroep, om- 
dat iedere geheugenwijziging in beide processen optreedt totdat de execve plaats- 
vindt. Een andere mogelijkheid bestaat hierin dat alle pagina’s gemeenschappe- 
lijk worden gebruikt door middel van het dupliceren van de paginatabel, maar 
dan moeten de ingangen in beide paginatabellen worden gemerkt als copy-on- 
write (kopieer-alvorens-erin-te-schrijven). De beveiligingsbits in de apparatuur 
worden zo gezet dat ze iedere poging tot schrijven in deze gemeenschappelijk 
gebruikte pagina’s ’in de val’ laten lopen. Als zo’n val optreedt, wordt er een 
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nieuw paginakader toegewezen en wordt de gemeenschappelijk gebruikte pagina 
naar het nieuwe kader gekopieerd. De paginatabellen worden aangepast om aan 
te geven dat deze pagina niet langer gemeenschappelijk gebruikt wordt (en daar- 
om niet langer schrijf-beveiliging nodig heeft), waarna de uitvoering kan worden 
hervat. Fouten in de apparatuur van de VAX/750 waren er de oorzaak van dat 
er geen ‘copy-on-write’ fork-bewerking in 4.2BSD kon worden opgenomen. 

Een execve-systeemaanroep creëert geen nieuwe proces- of gebruikersstruc- 
tuur; in plaats daarvan worden de tekst en de gegevens van het proces vervangen. 
Open bestanden worden intact gehouden (hoewel er een manier is om aan te 
geven dat zekere bestandsbeschrijvers als gevolg van een execve gesloten moeten 
worden). De meeste signaalbehandelingseigenschappen worden intact gelaten, 
maar maatregelen voor het aanroepen van een bepaalde gebruikersroutine als 
gevolg van een signaal worden om redenen die duidelijk zijn tenietgedaan. Het 
procesidentificatienummer en de meeste andere eigenschappen van het proces 
blijven ongewijzigd. 


14.6.2 CVE-werkindeling 


CVE-werkindeling in Unix is ervoor ontworpen dat interactieve processen wor- 
den bevoordeeld. De processen krijgen door een prioriteitsalgoritme, dat voor 
CVE-gebonden jobs neerkomt op een ’bij toerbeurt’ algoritme, kleine CVE-tijd- 
schijfjes. Met elk proces is een werkindelingsprioriteit verbonden; hoe groter het 
getal, hoe lager de prioriteit. Processen die met schijf-I/O of andere belangrijke 
taken bezig zijn, hebben negatieve prioriteiten en kunnen niet door signalen voor- 
tijdig beëindigd worden. Gewone processen in gebruikersfase hebben positieve 
prioriteiten en hebben daarom minder kans te worden uitgevoerd dan welk pro- 
ces in systeemfase ook, hoewel processen in gebruikersfase op elkaar voorrang 
kunnen hebben: de nice-opdracht is hierop van invloed. 

Hoe meer CVE-tijd een proces gebruikt, hoe lager (meer positief) zijn prio- 
riteit wordt en omgekeerd. CVE-werkindeling vertoont dus een negatieve terug- 
koppeling, zodat moeilijk één proces alle CVE-tijd op kan maken. Er wordt van 
procesveroudering gebruik gemaakt om uithongering te voorkomen. 

Oudere Unix-systemen gebruikten een quantum van één seconde voor de 
werkindeling bij toerbeurt: 4.2BSD onderwerpt de processen elke 1/10 seconde 
aan een nieuwe werkindeling en berekent na iedere seconde opnieuw de prioritei- 
ten. De werkindeling bij toerbeurt wordt tot stand gebracht door het mechanisme 
van de timeout (blokkeertijd), dat het stuurprogramma voor onderbreking door 
het tijdregister opdracht geeft na een opgegeven tijdsinterval een kern-subroutine 
aan te roepen. De subroutine die aangeroepen wordt veroorzaakt in dit geval een 
nieuwe werkindeling en geeft hieraan een nieuwe timeout af om zichzelf weer aan 
te roepen. De tijd voor het opnieuw berekenen van de prioriteiten wordt ook 
gezet door een subroutine die opnieuw een timeout voor zichzelf afgeeft. 

In de kern wordt geen enkel proces voortijdig onderbroken door een ander 
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proces. Een proces kan de CVE vrijgeven omdat het op I/O wacht, of omdat zijn 
tijdschijfje is verlopen. Wanneer een proces de CVE verkiest vrij te geven, gaat 
het slapen en wacht het op een gebeurtenis (Engels: event). De elementaire kern- 
functie die hiervoor gebruikt wordt, wordt slaap (Engels: sleep) genoemd; deze 
functie mag niet verward worden met de bibliotheekroutine op gebruikersniveau 
die net zo heet. De functie accepteert een argument, dat volgens afspraak het 
adres is van een kern-gegevensstructuur die verwant is met een gebeurtenis die het 
proces wil doen plaatsvinden voordat het gewekt wordt. Wanneer de gebeurtenis 
optreedt, roept het proces in systeemfase dat hiervan op de hoogte is word wakker 
(Engels: wakeup) aan met het adres dat met de gebeurtenis correspondeert. Alle 
processen die op hetzelfde adres deslaap-functie hadden aangeroepen, worden in 
de gereed-wachtrij geplaatst om uitgevoerd te worden. 

Bijvoorbeeld zal een proces dat op het gereedkomen van schijf-1/O wacht, 
een slaap-aanroep doen op het adres van de bufferkop die overeenkomt met de 
gegevens die worden overgebracht. Wanneer de onderbrekingsroutine voor het 
stuurprogramma voor de schijf in de gaten heeft dat de overdracht van de gege- 
vens klaar is, roept het een word wakker op het bufferkopgedeelte aan. De onder- 
breking gebruikt de kernstapel voor het proces dat op op dat moment aan zijn 
uitvoering bezig is, en de word wakker wordt vanuit de systeemfase van dat proces 
gedaan. 

Het proces dat werkelijk aan zijn uitvoering bezig is, is daartoe uitgekozen 
door de werkindeler. Slaap accepteert een tweede argument: de werkindelings- 
prioriteit die voor dat doel gebruikt moet worden. Een negatief prioriteitsar- 
gument verhindert tevens dat het proces wordt gewekt door een of andere uitzon- 
derlijke gebeurtenis, zoals een signaal. 

Wanneer er een signaal wordt gegenereerd, wordt het in een wachtrij gezet 
tot de systeemfase van het proces dat hierdoor beïnvloed wordt vervolgens aan 
zijn uitvoering bezig is. Dit gebeurt gewoonlijk spoedig, daar het signaal er nor- 
maal gesproken voor zorgt dat het proces wordt gewekt als het op een andere 
conditie stond te wachten. 

Met gebeurtenissen is geen geheugen gemoeid en degene die de routine, die 
in afwachting van een gebeurtenis een slaap doet, aanroept moet rekening houden 
met een voortijdige terugkeer, met onder andere de mogelijkheid dat de reden 
voor het wachten niet meer geldt. 

Het gebeurtenis-mechanisme kent ook hardloop-condities (Engels: race con- 
ditions). Als een proces (bijvoorbeeld na het controleren van een vlag in het ge- 
heugen) besluit om in afwachting van een gebeurtenis te gaan slapen, en de ge- 
beurtenis treedt al op voordat het proces de functie, die de eigenlijke slaap in 
afwachting van de gebeurtenis doet, kan uitvoeren, zou het proces wel altijd door 
kunnen slapen. Dit wordt voorkomen door gedurende de kritieke sectie de prio- 
riteitsvlag van de CVE te zetten, zodat er geen onderbrekingen kunnen optreden; 
op die manier kan het proces dat de gebeurtenis wenst ononderbroken worden 
uitgevoerd tot dit gaat slapen. De prioriteitsvlag van de CVE wordt op deze ma- 
nier gebruikt om kritieke regio’s door de gehele kern te beveiligen; dit is het 
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grootste obstakel voor de overdraagbaarheid van Unix naar machines met meer 
dan één processor. 

Veel processen, zoals tekstopmaakprogramma’s, zijn I/O-gebonden en zul- 
len gewoonlijk voornamelijk door de werkindeler worden geselecteerd omdat ze 
staan te wachten op I/O. De ondervinding leert dat de werkindeler in Unix de 
beste prestaties levert bij 1/O-gebonden jobs. Dit kan men waarnemen wanneer 
er verschillende CVE-gebonden jobs, zoals tekstopmaakprogramma’s of taalver- 
tolkers, draaien. 

Wat hier CVE-werkindeling genoemd werd komt nauw overeen met de 
werkindeling op korte termijn uit hoofdstuk 4, hoewel de eigenschap van negatieve 
terugkoppeling van het werken met prioriteiten een zekere werkindeling op lange 
termijn oplevert in deze zin dat hierdoor grotendeels de job-mengverhouding (job 
mix) op lange termijn bepaald wordt. Werkindeling op middellange termijn wordt 
verkregen met het hierna te beschrijven mechanisme van programmaverwisseling. 
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Veel van het eerste ontwikkelingswerk aan Unix vond plaats op een PDP-11. De 
PDP-11 heeft slechts acht segmenten in zijn virtuele adresruimte, en elk van deze 
segmenten beslaat hoogstens 8192 bytes. De grotere machines, zoals de PDP- 
11/70, bieden de mogelijkheid van afzonderlijke instructie- en adresruimten, die 
de geheugenruimte en het aantal segmenten effectief verdubbelen, maar dit is 
nog niet veel. Bovendien waren er nog zwaardere beperkingen aan de kern opge- 
legd, omdat één gegevenssegment uitsluitend bestemd was voor onderbrekings- 
vectoren, een ander om naar het systeemgegevenssegment voor elk proces te wij- 
zen, en nog weer een ander voor de UNIBUS-registers. Verder was op de kleinere 
PDP-11 machines het totale fysieke geheugen beperkt tot 256K bytes. Alle geheu- 
genelementen bij elkaar waren ontoereikend voor het rechtvaardigen of onder- 
steunen van complexe algoritmen voor geheugenbeheer. Daarom moest Unix 
steeds het gehele proces-geheugenbeeld uit het geheugen zetten en daarin weer 
terugbrengen door middel van programmaverwisseling. 


14.7.1 Programmaverwisseling 


Unix-systemen van vóór 3BSD maakten alleen maar van programmaverwisseling 
gebruik om de wedijver om geheugen tussen processen te behandelen: als er te- 
veel wedijver is, worden er processen uit het hoofdgeheugen gezet tot er genoeg 
geheugen beschikbaar is. Hierbij kan het gebeuren dat een paar grote processen 
vele kleine processen uit het geheugen persen; en een proces dat groter is dan het 
hoofdgeheugen buiten de kern kan al helemaal niet draaien. Het systeemgege- 
venssegment (de g-structuur en de kernstapel) en het gebruikersgegevenssegment 
(tekst indien deze niet gemeenschappelijk wordt gebruikt, gegevens en de stapel) 
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worden in aaneengesloten gedeelten van het hoofdgeheugen bewaard om de pro- 
grammaverwisseling efficiënt te laten verlopen. Daarom kan externe fragmentatie 
van het geheugen een ernstig probleem vormen. 

De toewijzing van zowel het hoofdgeheugen als de ruimte voor program- 
maverwisseling vindt plaats volgens eerst-passend. Wanneer de grootte van het 
geheugenbeeld van een proces toeneemt (hetzij door uitbreiding van de stapel, 
hetzij door uitbreiding van de gegevens), wordt een nieuw stuk geheugen toegewe- 
zen dat groot genoeg is voor het gehele geheugenbeeld. Het geheugenbeeld wordt 
gekopieerd, het oude geheugen wordt vrijgegeven, en de juiste tabellen worden 
bijgewerkt. (In sommige systemen wordt getracht om aaneengesloten geheugen 
aan het eind van het huidige gedeelte te vinden om een deel van het kopiëren te 
vermijden.) Als geen aaneengesloten gedeelte van het hoofdgeheugen groot ge- 
noeg is, wordt het proces op zo’n manier uit het geheugen gezet dat het daarin 
later in de nieuwe grootte terugkomt. 

Het is niet nodig een tekstsegment dat gemeenschappelijk gebruikt kan 
worden uit het geheugen te zetten, omdat het alleen-uitleesbaar is en er geen 
tekstsegment voor gemeenschappelijk gebruik ingelezen hoeft te worden als een 
andere kopie daarvan al in het geheugen is. Dit is een van de voornaamste rede- 
nen om gemeenschappelijk gebruikte tekstsegmenten in de gaten te houden: min- 
der programmaverwisselingsactiviteit. De andere reden is dat er minder hoofdge- 
heugen vereist is voor meerdere processen wanneer die hetzelfde tekstsegment 
gebruiken. 

Beslissingen zoals welke processen in of uit het geheugen gezet moeten wor- 
den, worden door het programaverwisselproces genomen: proces 0. De program- 
maverwisselaar wordt op zijn minst elke vier seconden wakker om te controleren 
of er processen zijn die in of uit het geheugen gezet moeten worden. Een proces 
loopt meer kans om uit het geheugen gezet te worden als het niets te doen heeft, 
al lang in het hoofdgeheugen heeft verbleven, of als het groot is; als het niet 
gemakkelijk is er één proces uit te pikken worden andere processen genomen op 
grond van hun leeftijd. Een proces heeft meer kans weer in het geheugen terug 
te keren als het al lang geleden uit het geheugen werd gezet, of als het klein is. 
Er worden controles uitgevoerd om ’stampen’ te voorkomen. De basis hiervoor 
is dat een proces niet uit het geheugen gezet wordt als het niet gedurende een 
zekere tijd in het hoofdgeheugen geweest is. 

Als er geen jobs uit het hoofdgeheugen gezet hoeven te worden, wordt de 
procestabel doorzocht om een proces te vinden dat verdient om weer in het ge- 
heugen teruggebracht te worden (wat wordt bepaald op grond van hoe klein het 
is en hoe lang het buiten het geheugen geweest is). Als er niet genoeg geheugen 
beschikbaar is, worden processen uit het geheugen gezet totdat er wel ruimte 
genoeg is. 

In 4.2BSD wordt ruimte voor programmaverwisseling toegewezen in stuk- 
ken die veelvouden zijn van een macht van twee en die liggen tussen een mi- 
nimumgrootte (bijvoorbeeld 32 pagina’s) en een maximumgroote die wordt be- 
paald door de grootte van een partitie voor programmaverwisseling op de schijf. 
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Als er verschillende logische schijfpartities voor programmaverwisseling gebruikt 
kunnen worden, moeten die om deze reden dezelfde grootte hebben. De verschil- 
lende logische schijfpartities moeten zich ook onder verschillende schijfarmen 
bevinden, om de zoekbewerkingen op schijf zo klein mogelijk te houden. 

Veel Unix-systemen maken nog steeds gebruik van de manier van program- 
maverwisseling zoals die hiervoor beschreven is. Alle USG-systemen met release- 
nummers lager dan V.3 doen dat ook. Alle Unix-systemen van Berkeley, met 
inbegrip van 4.2BSD, gebruiken voor hun geheugenbeheer in de eerste plaats 
paginering, en pas in de tweede plaats programmaverwisseling. Er wordt een 
methode gebruikt om vast te stellen welke processen in of uit het geheugen gezet 
moeten worden die zeer veel lijkt op de traditionele methode, maar deze verschilt 
op kleine punten en de invloed van programmaverwisseling is minder groot. 


14.7.2 Paginering 


Berkeley bracht paginering aan in Unix met 3BSD. 4.2BSD is een systeem met 
virtueel geheugen en paginering op verzoek. Externe fragmentatie van het geheu- 
gen wordt door paginering geëlimineerd. (Er bestaat natuurlijk interne fragmen- 
tatie, maar bij een redelijk kleine paginagrootte kan deze worden verwaarloosd.) 
Programmaverwisseling kan tot een minimum beperkt blijven, omdat er meer 
jobs in het hoofdgeheugen gehouden kunnen worden; ze behoeven zich immers 
niet in hun geheel in het geheugen te bevinden. 

Pagineren op verzoek gebeurt recht toe recht aan. Wanneer een proces een 
pagina nodig heeft en de pagina is er niet, dan gaat er een paginafoutmelding 
naar de kern, er wordt een kader uit het hoofdgeheugen toegewezen en de juiste 
pagina wordt van schijf daarin ingelezen. 

Er zijn een paar manieren om dit optimaal te laten verlopen. Als de pagina 
die voor het proces nodig is zich nog in de paginatabel bevindt, maar als ongeldig 
is gemerkt door het proces dat de paginavervanging verzorgt, kan deze als geldig 
worden gemerkt en zonder enige 1/O-overbrenging worden gebruikt. Op soortge- 
lijke wijze kunnen pagina’s worden teruggevonden in de lijst met vrije kaders. 
Wanneer de meeste processen begonnen zijn worden vele van hun pagina’s voor- 
gepagineerd en op de vrije-kaderlijst gezet om door dit mechanisme te worden 
gevonden. Er kunnen regelingen worden getroffen zodat een proces bij het begin 
geen paginering vooraf heeft, maar dit wordt zelden gedaan omdat het meer over- 
head als gevolg van paginafouten oplevert, waar het dichter bij zuiver pagineren 
op verzoek komt. 

Als de pagina van de schijf moet komen, moet deze voor de duur daarvan 
worden geblokkeerd. Is de pagina eenmaal opgehaald en op de juiste manier 
vertaald, dan moet de blokkering ervan niet worden opgeheven als er echt fysieke 
I/O op plaatsvindt. 

Het algoritme voor paginavervanging is interessanter. De VAX heeft geen 
paginaverwijzingsbit in de geheugenapparatuur. Dit maakt veel van de algorit- 
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men voor geheugenbeheer, zoals dat gebaseerd op paginafoutfrequentie, onbruik- 
baar. 4.2BSD gebruikt een gewijzigd Minst-Recent-Gebruikt (MRG) algoritme 
dat werkt volgens een globale klok. Een geprogrammeerde klokwijzer maakt li- 
neair en regelmatig een rondgang door de vertaaltabel van al het hoofdgeheugen 
dat niet tot de kern behoort (de inwendige-geheugentabel, Engels: core map of 
cmap). Wanneer de wijzer een bepaald kader bereikt en het kader als in gebruik 
gemarkeerd is door een of andere programmatuur-conditie (bijvoorbeeld, fysieke 
I/O maakt er op dit moment gebruik van), of het kader is al vrij, dan wordt het 
onaangeroerd gelaten en gaat de wijzer verder naar het volgende kader. Anders 
wordt de ingang in de paginatabel van de daarmee corresponderende tekst of het 
ermee corresponderende proces opgezocht. Als de ingang al ongeldig is gemaakt, 
wordt het kader aan de vrije-kaderlijst toegevoegd, anders wordt de ingang van 
de paginatabel ongeldig maar opnieuw-opeisbaar gemaakt (dat wil zeggen, de 
pagina kan, als hij de volgende keer dat hij nodig is niet uitgepagineerd is, gewoon 
weer geldig gemaakt worden). Natuurlijk moet de pagina als deze gemodificeerd 
is (de VAX heeft inderdaad een mutatiebit) eerst naar schijf worden weggeschre- 
ven voordat deze aan de vrije-kaderlijst wordt toegevoegd. 

Er zijn controles om er zeker van te zijn dat het aantal geldige pagina’s met 
gegevens voor een proces niet te klein wordt en de pagineereenheid niet met 
verzoeken wordt overstroomd. Er is ook een mechanisme waarmee een proces de 
hoeveelheid intern geheugen die het gebruikt kan beperken. 

De MRG-klokwijzer is geïmplementeerd in de pagineerdemon; dit is proces 
2 (denk eraan dat het programmaverwissel-proces 0 en init proces 1 is). Dit proces 
slaapt het grootste gedeelte van de tijd, maar er vindt diverse malen per seconde 
een controle plaats (opgezet door een timeout) om te zien of er actie nodig is, en 
zo ja, dan wordt proces 2 gewekt. Telkens wanneer het aantal vrije kaders be- 
neden een drempelwaarde veelvrij komt, wordt de pagineerdemon gewekt; op deze 
wijze legt de pagineerdemon geen extra belasting op het systeem als er veel vrij 
geheugen is, omdat hij dan nooit wordt gewekt. 

De rondgang van de klokwijzer telkens wanneer het pagineerdemon-proces 
wordt gewekt (dat wil zeggen dat de kaders zijn langsgelopen, waarvan er ge- 
woonlijk meer zijn dan het aantal pagina’s dat uitgepagineerd is), wordt bepaald 
door zowel het aantal kaders dat ontbreekt om veelvrij te halen als het aantal 
kaders waarvan de programmaverwisselaar heeft bepaald dat deze om tal van 
redenen nodig zijn (hoe meer kaders er nodig zijn, hoe langer de rondgang). Als 
het aantal vrije kaders oploopt tot veelvrij voordat de verwachte rondgang is vol- 
tooid, stopt de wijzer en gaat het pagineerdemon-proces weer slapen. De parame- 
ters die de reikwijdte van de rondgang van de klokwijzer bepalen worden bij 
het starten van het systeem aan de hand van de hoeveelheid intern geheugen zó 
vastgesteld dat de pagineerdemon niet meer dan 10% van de totale CVE-tijd zal 
gebruiken. 

Als de programmaverwisselaar beslist dat het pagineersysteem te zwaar be- 
last is, zullen processen uit het geheugen gezet worden tot de extra werklast bin- 
nen redelijke proporties is teruggebracht. Dit gebeurt gewoonlijk alleen dan wan- 


14.7 Geheugenbeheer 549 


neer aan diverse voorwaarden is voldaan: gemiddeld hoge belasting, de hoeveel- 
heid vrij geheugen is beneden een zeer lage grens minvrij gedaald, en de gemiddel- 
de hoeveelheid beschikbaar geheugen is gedurende een recente tijdsperiode 
minder dan een wenselijke hoeveelheid wensvrij, waarbij veelvrij >> wensvrij >> 
minvrij. Met andere woorden, slechts een chronisch gebrek aan geheugen, waarbij 
diverse processen proberen te draaien zal programmaverwisseling veroorzaken, 
en zelfs dan moet de hoeveelheid vrij geheugen op dat moment erg klein zijn. 
(Een buitengewoon hoge pagineerfrequentie of een geheugenbehoefte van de kern 
zelf kan in uitzonderlijke gevallen ook deel uitmaken van de berekeningen.) 
Processen kunnen natuurlijk door de programmaverwisselaar om andere redenen 
uit het geheugen gezet worden (bijvoorbeeld als ze gedurende lange tijd niet ge- 
draaid hebben). 

De parameter veelvrij bedraagt gewoonlijk % van het geheugen in de tabel 
waarlangs de wijzer rondgaat en wensvrij en minvrij zijn gewoonlijk hetzelfde 
in verschillende systemen, maar ze zijn beperkt tot fracties van het beschikbare 
geheugen. 

Het tekstsegment van elk proces is, tenzij de gebruiker anders specificeert, 
een gemeenschappelijk gebruikt, alleen-uitleesbaar tekstsegment. Dit is handig 
bij pagineren, omdat er geen externe fragmentatie bij optreedt en de ruimte voor 
programmaverwisseling die men daarmee wint ruimschoots opweegt tegen de 
verwaarloosbare hoeveelheid extra werk die daarmee gepaard gaat. De virtuele 
geheugenruimte van de kern is immers groot. 

CVE-werkindeling, programmaverwisseling en paginering hebben invloed 
op elkaar: hoe lager de prioriteit van een proces, hoe waarschijnlijker het is dat 
zijn pagina’s uitgepagineerd zijn en ook dat het in zijn geheel uit het geheugen 
gezet zal zijn. 

De leeftijdsvoorkeur bij het kiezen van processen voor programmaverwis- 
seling biedt bescherming tegen ‘stampen’, maar paginering doet hetzelfde op een 
effectievere manier. In het ideale geval zullen processen niet door programmaver- 
wisseling uit het geheugen gezet worden tenzij zij werkeloos zijn, omdat elk pro- 
ces op elk moment alleen maar een kleine werkset pagina’s in het hoofdgeheugen 
heeft en de pagineerdemon ongebruikte pagina’s zal opeisen voor gebruik door 
andere processen; dus de meeste in verwerking zijnde processen zullen nooit vol- 
ledig uit het geheugen gezet zijn. 

De hoeveelheid geheugen die het proces nodig zal hebben bedraagt een 
zeker deel van zijn totale virtuele-geheugengrootte; dit mag maximaal de helft 
zijn (als het lang uit het geheugen geweest is). 

Voor een efficiënte I/O zijn de pagina’s in de VAX-apparatuur met hun 
512 bytes te klein. Daarom worden ze in groepjes van twee gebruikt, zodat alle 
paginerings-1/O in feite plaatsvindt in brokken van 1024 bytes. Met andere woor- 
den, de effectieve paginagrootte zit niet vastgebakken aan de paginagrootte in de 
apparatuur van de machine, al moet deze wel een veelvoud van de paginagrootte 
in de apparatuur zijn. [ 
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14.8 [/O-systeem 


Een van de doeleinden van een besturingssysteem is dat de bijzonderheden van 
specifieke randapparatuur aan het oog van de gebruiker worden onttrokken. Het 
bestandssysteem bijvoorbeeld biedt een eenvoudige, consequente opslagvoorzie- 
ning (het bestand) onafhankelijk van de daaraan ten grondslag liggende schijfap- 
paratuur. In Unix worden ook de bijzonderheden van de randapparatuur door 
het 1/O-systeem verborgen gehouden voor het merendeel van de kern zelf. Het 
I/O-systeem bestaat uit een systeem met buffergeheugens, algemene code voor 
het aansturen van de randapparatuur en stuurcode voor speciale randapparatuur. 
Slechts dit laatste deel, de stuurcode voor die randapparatuur, kent de bijzonder- 
heden van een specifiek randapparaat. 

De belangrijkste delen van het I/O-systeem kunnen schematisch worden 
voorgesteld zoals in figuur 14.10. 

Er zijn drie hoofdsoorten I/O in 4.2BSD: ’blokgeoriënteerde’ randappara- 
ten, ‘tekengeoriënteerde’ randapparaten en de contactdoos-koppeling (Engels: 
socket interface). De contactdoos-koppeling met zijn protocollen en netwerk- 
koppelingen zullen later in paragraaf 14.9.1. worden behandeld. 

Blokgeoriënteerde randapparaten zijn onder andere schijven en magneetban- 
den. Zij zijn hierdoor te onderscheiden dat zij rechtstreeks adresseerbaar zijn in 
blokken van een vaste grootte, gewoonlijk 512 bytes. Een stuurroutine voor een 
blokgeoriënteerd randapparaat moet details zoals sporen, cilinders, enzovoort, 
kunnen onderscheiden van de rest van de kern. Blokgeoriënteerde randapparaten 
zijn direct toegankelijk via geschikte speciale bestanden voor dat randapparaat 
(zoals /dev/rp0), maar ze worden gewoonlijk indirect benaderd via het bestands- 
systeem. In ieder geval worden overbrengingen gebufferd met behulp van het 

_ blok-buffertussengeheugen, dat een grondig effect op de efficiëntie heeft. 

Onder tekengeoriënteerde randapparaten vallen terminals en regeldrukkers, 
maar ook bijna ieder ander apparaat (afgezien van netwerkkoppelingen) dat geen 
gebruik maakt van het blok-buffertussengeheugen. Bijvoorbeeld, /dev/mem is 


systeemaanroep-koppeling met de kern 
gewoon bestand Re gene slimme terminal 
slimme primitieve primitieve 


protocollen bestands- blok- blok- terminal- lijnverkeers- 
systeem koppeling | koppeling koppeling regels 
koppeling met stuurroutine voor stuurroutine 
het netwerk blokapparatuur voor tekenapparatuur 


de apparatuur 


Figuur 14.10 
|/O-structuur van de 4.2BSD-kern 
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een koppeling met het fysieke hoofdgeheugen en /dev/null is een bodemloze af- 
voer voor gegevens en een eindeloze bron van ’einde-bestand’-markeringstekens. 
Sommige randapparaten, zoals snelle graphics-koppelingen kunnen hun eigen 
buffers hebben of ze kunnen altijd direct I/O uitvoeren in de gegevensruimte van 
de gebruiker; daar ze geen gebruik maken van het blok-buffertussengeheugen, 
worden ze in de klasse van tekengeoriënteerde randapparaten ingedeeld. 

Terminals, en apparaten die op terminals lijken, gebruiken C-lijsten: buffers 
die kleiner zijn dan die van het blok-buffertussengeheugen. 

‘Blokgeoriënteerde’ randapparaten en ’tekengeoriénteerde’ randapparaten 
vormen de twee hoofdklassen. Stuurroutines voor randapparatuur worden be- 
naderd via één van de twee reeksen van ingangsadressen (entry points’). De ene 
reeks is voor blokgeoriënteerde randapparaten; de andere is voor tekengeoriën- 
teerde randapparaten. Een randapparaat wordt onderscheiden naar zijn klasse 
(blok- of tekengeoriënteerd) en een randapparaatnummer. Het randapparaatnum- 
mer bestaat uit twee gedeelten. Het hoofdnummer van het randapparaat wordt 
gebruikt als index in de array voor blok- of tekengeoriënteerde randapparaten 
om ingangen in de juiste stuurcode te vinden. Het bijnummer van het randapparaat 
wordt door de stuurcode van het randapparaat geïnterpreteerd als, bijvoorbeeld, 
een logische partitie op de schijf of een terminallijn. 

De stuurcode voor randapparatuur is met de rest van de kern alleen verbon- 
den door de ingangsadressen die vastliggen in de reeks voor zijn klasse en door 
het gebruik door de stuurcode van gemeenschappelijke buffersystemen. Deze 
scheiding is belangrijk met het oog op de overdraagbaarheid en ook het configu- 
reren van systemen. 


14.8.1 Blok-buffertussengeheugen 


De blokgeoriënteerde randapparaten maken gebruik van een blok-buffertussen- 
geheugen. Het blok-buffertussengeheugen bestaat uit een aantal bufferkop- 
gedeelten, waarvan elk naar een stuk fysiek geheugen wijst en ook naar een rand- 
apparaatnummer en het nummer van een blok op het randapparaat. De buffer- 
kopgedeelten worden in verscheidene aaneengeschakelde lijsten bewaard. 


@ Informatie die nooit wordt weggeschreven, zoals superblokken van bestands- 
systemen. 

@ Blokken die in gebruik zijn (het tussengeheugen) in minst-recent-gebruikt 
volgorde. 

@ Lege buffers waarmee geen geheugen of blokken op schijf verbonden zijn. 


De buffers in deze lijsten zijn ook ge’hashed’ op randapparaat- en bloknummer 
om het zoeken efficiënter te laten verlopen. 

Wannneer een blok van een randapparaat wordt verlangd (een leesop- 
dracht), wordt het tussengeheugen doorzocht. Als het blok gevonden wordt, 
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wordt het gebruikt en is er geen I/O nodig. Wordt het niet gevonden, dan wordt 
uit de lijst van lege buffers een buffer uitgekozen, het randapparaat- en bloknum- 
mer die daarmee verband houden worden bijgewerkt, er wordt geheugen voor 
gevonden en de nieuwe gegevens worden van het randapparaat daarnaar overge- 
bracht. Als er geen lege buffers zijn, wordt de minst-recent-gebruikte buffer naar 
het daarbij behorende randapparaat geschreven en wordt de buffer opnieuw ge- 
bruikt. 

Bij een schrijfopdracht worden, als het betreffende blok al in het blok- 
buffertussengeheugen is, de nieuwe gegevens in de buffer gezet (waardoor alle 
voorgaande gegevens overschreven worden), het bufferkopgedeelte krijgt een in- 
dicatie dat de buffer gewijzigd is; I/O is niet onmiddellijk nodig. De gegevens 
worden weggeschreven wanneer de buffer voor andere gegevens nodig is. Wordt 
het blok niet in het blok-buffertussengeheugen gevonden, dan wordt een lege 
buffer uitgezocht (evenals bij een leesopdracht) en worden de gegevens naar deze 
buffer overgebracht. 

Met regelmatige tussenpozen worden gewijzigde bufferblokken geforceerd 
weggeschreven om potentiële inconsistenties in het bestandssysteem na een sys- 
teemstoring tot een minimum te beperken. 

De hoeveelheid gegevens in een buffer in 4.2BSD is variabel, met een maxi- 
mum voor het totaal van alle bestandssystemen, gewoonlijk 8K bytes. De mi- | 
nimumgrootte is gelijk aan de grootte van het paginablok, gewoonlijk 1024 bytes. 
Buffergrenzen vallen samen met de grenzen van paginablokken, zodat elk pagina- 
blok aan slechts één buffer tegelijk kan worden gerelateerd, evenals elk schijfblok 
slechts met één buffer tegelijk overeenkomt. 

De hoeveelheid gegevens in een buffer kan toenemen naarmate een gebrui- 
ker meer gegevens schrijft na die welke al in de buffer zijn. Wanneer dit gebeurt 
wordt een nieuwe buffer toegewezen die groot genoeg is om alle gegevens te 
bevatten en worden de oorspronkelijke gegevens daarin gekopieerd, gevolgd door 
de nieuwe gegevens. Als een buffer slinkt wordt er een buffer van de wachtrij 
van lege buffers gehaald, het teveel aan pagina’s wordt erin gezet en die buffer 
wordt vrijgegeven om naar de schijf weggeschreven te worden. 

Voor sommige randapparaten, zoals magneetbanden, is het nodig dat blok- 
ken in een bepaalde volgorde worden weggeschreven; dus zijn er voorzieningen 
geleverd om synchrone schrijfbewerkingen van buffers naar deze randapparaten 
af te dwingen. Blokken van adresboeken worden ook synchroon geschreven. 

De grootte van het blok-buffertussengeheugen kan een vergaand effect heb- 
ben op het prestatievermogen van het systeem, omdat als het groot genoeg is het 
percentage treffers op het blok-buffertussengeheugen heel hoog en het aantal 
werkelijke I/O-bewerkingen dus laag kan zijn. 

Er zijn een paar interessante interacties tussen het blok-buffertussengeheu- 
gen, het bestandssysteem en de stuurroutines voor de schijf. Wanneer gegevens 
naar een schijfbestand worden geschreven, worden deze in de buffers van het 
blok-buffertussengeheugen opgeslagen en sorteert de schijfstuurroutine zijn uit- 
voer-wachtrij op schijfadres. Deze twee zaken maken het mogelijk dat de schijf- 
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stuurroutine zoekbewerkingen op schijf tot een minimum beperkt en dat het de 
gegevens wegschrijft op tijdstippen die optimaal zijn gekozen met betrekking tot 
de schijfrotatie. Wanneer gegevens uit een schijfbestand worden gelezen, leest het 
blok-I/O-systeem een paar blokken vooruit; leesbewerkingen gebeuren echter 
vaker asynchroon dan schrijfbewerkingen. Daarom gaat bij overbrenging van 
grote hoeveelheden gegevens, in tegenstelling tot wat men misschien zou ver- 
wachten, uitvoer naar schijf via het bestandssysteem dikwijls sneller dan invoer. 


14.8.2 Primitieve koppeling met de randapparatuur 


Bijna elk blokgeoriënteerd randapparaat heeft ook een teken-koppeling, die 
primitieve koppeling met de randapparatuur wordt genoemd. Zo’n koppeling ver- 
schilt van de blok-koppeling in deze zin dat voorbijgegaan wordt aan het blok- 
buffertussengeheugen. 

Elke stuurroutine voor schijf houdt een wachtrij bij van overbrengingen 
die nog gaande zijn. Elk record in de wachtrij geeft aan of het een lees- of een 
schrijfbewerking is, een adres in het hoofdgeheugen voor de overbrenging, een 
randapparaatadres voor de overbrenging (gewoonlijk het nummer van het blok 
van 512 bytes) en een overbrengingsgrootte (in bytes). Het is een eenvoudige zaak 
de informatie uit een blokbuffer te vertalen naar wat voor deze wachtrij nodig 
is. 

Het is bijna even eenvoudig om op soortgelijke wijze een stuk van het 
hoofdgeheugen te vertalen naar een gedeelte van de virtuele adresruimte van een 
gebruikersproces. Dit is wat bijvoorbeeld een primitieve schijf-koppeling doet. 
Op die manier is het mogelijk gegevens rechtstreeks naar of van de virtuele adres- 
ruimte van een gebruiker over te brengen. Het aantal bytes dat zo kan worden 
overgebracht hangt af van het fysieke randapparaat; sommige randapparaten 
vereisen dat dit een even aantal bytes is. De programmatuur beperkt soms de 
grootte van een enkele overbrenging tot wat er in een woord van 16 bits kan; dit 
is een produkt van de geschiedenis van het systeem PDP-11 en van de PDP-11 
ontwikkelingslijn van veel van de randapparaten zelf. 

De kern verricht de overbrenging voor programmaverwisseling en pagine- 
ring gewoon door het juiste verzoek in de wachtrij voor het juiste randapparaat 
te zetten. Er is geen aparte stuurroutine nodig voor de programmaverwisselings- 
of pagineereenheid. 

De implementatie van het bestandssysteem in 4.2BSD werd in feite geschre- 
ven en getest als een gebruikersproces dat gebruik maakte van een primitieve 
koppeling met de schijf, voordat de code naar de kern werd overgebracht. 


14.8.3 C-lijsten 


Stuurroutines voor terminals gebruiken een systeem gebaseerd op het in buffers 
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opslaan van tekens. Hierbij worden kleine blokken tekens (gewoonlijk 28 bytes) 
bewaard in aaneengeschakelde lijsten. Er zijn routines die tekens in en uit zulke 
lijsten zetten. Hoewel alle vrije-tekenbuffers in een enkele vrije lijst worden be- 
waard, beperken de meeste stuurroutines voor randapparatuur die ze gebruiken 
het aantal tekens dat voor een terminallijn in één keer in de rij gezet kan worden. 

Een systeemaanroep voor een schrijfbewerking naar een terminal zet tekens 
in de wachtrij voor het randapparaat. Er wordt met een overbrenging begonnen 
en onderbrekingen zorgen ervoor dat tekens uit de wachtrij gehaald worden en 
verdere overbrengingen plaatsvinden. | 

Op soortgelijke manier is invoer onderbrekinggestuurd. Stuurprogramma's 
voor terminals ondersteunen echter meestal twee invoer-wachtrijen, waarbij con- 
versie van de eerste (de primitieve wachtrij) naar de andere (de canonieke wacht- 
rij) in gang wordt gezet door de onderbrekingsroutine, wanneer deze een ’einde 
regel’-teken in de primitieve wachrij zet. Het proces, dat een leesbewerking op 
het randapparaat uitvoert, wordt dan gewekt en de systeemfase daarvan verricht 
de conversie. De tekens die op deze wijze in de canonieke wachrij worden gezet 
zijn dan beschikbaar om aan het gebruikersproces door de leesopdracht te wor- 
den geretourneerd. 

Het is ook mogelijk dat de stuurroutine met voorbijzien van de canonieke 
wachtrij tekens rechtstreeks vanuit de primitive wachtrij retourneert. Dit staat 
bekend als de ’primitieve werkwijze’ (Engels: ‘raw mode’). 


14.9 Communicatie tussen processen 


Vele taken kunnen in geisoleerde processen worden verricht, maar vele andere 
vereisen communicatie tussen processen. Geisoleerde computersystemen hebben 
lange tijd dienst gedaan voor tal van toepassingen, maar het gebruik van netwer- 
ken wordt steeds belangrijker. Met het toenemende gebruik van werkstations 
komt het gemeenschappelijke gebruik van systeemfaciliteiten vaker voor. Com- 
municatie tussen processen is van oudsher niet een van de sterke punten van 
Unix geweest. 

De meeste Unix-systemen stonden geen gemeenschappelijk geheugen (En- 
gels: shared memory) toe, omdat de apparatuur van de PDP-11 dit niet aanmoe- 
digde. Systeem V ondersteunt wél een gemeenschappelijk geheugen en dit was 
ook gepland voor 4.2BSD, maar het werd niet geïmplementeerd wegens tijdge- 
brek. In ieder geval vormt gemeenschappelijk geheugen een probleem in een net- 
werkomgeving, daar toegang tot het netwerk nooit zo snel kan zijn als toegang 
tot het geheugen op de lokale machine. Hoewel men natuurlijk zou kunnen doen 
alsof twee afzonderlijke machines gemeenschappelijk geheugen hadden door on- 
zichtbaar gegevens over een netwerk te kopiëren, zou desondanks het belangrijk- 
ste voordeel van gemeenschappelijk geheugen (snelheid) verloren gaan. 
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14.9.1 Contactdozen (sockets) 


De pijp (besproken in paragraaf 14.4.3) is het meest karakteristieke IPC- 
mechanisme van Unix (IPC staat voor ’Inter-Process Communication’, ofwel de 
communicatie tussen processen). Een pijp maakt een betrouwbare byte-stroom 
in één richting tussen twee processen mogelijk. Vanouds is deze geïmplementeerd 
als een gewoon bestand, op een paar uitzonderingen na. In het bestandssysteem 
staat een pijp niet onder een bepaalde naam bekend, omdat hij in plaats daarvan 
wordt opgezet door de pijp-systeemaanroep. De grootte ervan ligt vast en wan- 
neer een proces probeert naar een volle pijp te schrijven wordt de uitvoering 
van het proces opgeschort. Zijn alle gegevens die voordien naar de pijp waren 
geschreven eenmaal uitgelezen, dan gaat het schrijven verder aan het begin van 
het bestand (pijpen zijn niet echte cirkelvormige buffers). Eén voordeel van de 
kleine afmeting (gewoonlijk 4096 bytes) van pijpen is dat gegevens in een pijp 
zelden ook echt naar schijf worden geschreven, omdat deze gewoonlijk in het 
geheugen worden bewaard met behulp van het normale blok-buffertussengeheu- 
gen. 

In 4.2BSD zijn pijpen geïmplementeerd als een speciaal geval van het 
contactdoos-mechanisme (Engels: socket). Het contactdoos-mechanisme in 
4.2BSD maakt een algemene koppeling mogelijk niet alleen met voorzieningen 
als pijpen, die lokaal zijn voor één machine, maar ook met netwerkvoorzieningen. 

Een contactdoos is een communicatie-eindpunt. Met een contactdoos die in 
gebruik is, is gewoonlijk een adres verbonden. De aard van het adres hangt af 
van het communicatiedomein van de contactdoos. Een karakteristieke eigenschap 
van een domein is dat processen die binnen hetzelfde domein communiceren 
hetzelfde adresformaat gebruiken. Eén contactdoos kan slechts in één domein 
communicatie verzorgen. 

De twee domeinen die momenteel in 4.2BSD zijn geïmplementeerd zijn het 
Unix-domein (AF—Unix) en het Internet-domein (AF—INET). Het adresfor- 
maat van het Unix-domein bestaat uit de gewone padnamen van het bestandssys- 
teem, zoals /alpha/ beta/ gamma. Processen die met elkaar in het Internet-domein 
communiceren gebruiken DARPA Internet-communicatieprotocollen (zoals 
TCP/IP) en Internet-adressen, die uit een gastheer-computernummer van 32 bits 
en een poortnummer van 32 bits bestaan. 

Er zijn diverse typen contactdozen, die overeenkomen met bepaalde klassen 
van dienstverlening. Elke type kan al of niet in een communicatiedomein geïm- 
plementeerd zijn. Als een type in een bepaald domein geïmplementeerd is, kan 
het geïmplementeerd zijn met behulp van een of meer protocollen die door de 
gebruiker geselecteerd kunnen zijn. 


@ Stroom-contactdozen geven betrouwbare, duplex, sequentiële gegevensstro- 
men. Er gaan geen gegevens verloren, er komen geen gegevens dubbel aan, en 
er zijn geen recordgrenzen. Dit type wordt ondersteund in het Internet-domein 
door het TCP-protocol. In het Unix-domein zijn de pijpen als een paar met 
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elkaar communicerende stroom-contactdozen geïmplementeerd. 

@ Sequentieel-pakket-contactdozen leveren gegevensstromen als die van de 
stroomcontactdozen, behalve dat er recordgrenzen gelden. Dit type wordt mo- 
menteel niet ondersteund, maar komt overeen met het XNS-protocol van Xe- 
Tox. 

@ Datagram-contactdozen brengen berichten van elke grootte over in beide rich- 
tingen. Er is geen garantie dat zulke berichten in dezelfde volgorde aankomen 
als die waarin ze werden verzonden, of dat ze niet dubbel zullen aankomen, 
of dat ze ooit aankomen, maar de afmeting van het oorspronkelijke bericht 
(record) is bewaard in elk datagram dat aankomt. Dit type wordt ondersteund 
in het Internet-domein door middel van het UDP-protocol. 

@ Betrouwbaar-afgeleverd-bericht-contactdozen brengen berichten over waarvan 
wordt gegarandeerd dat ze aankomen; deze berichten komen overigens over- 
een met de berichten die worden overgebracht met gebruikmaking van data- 
gram-contactdozen. Dit type wordt momenteel niet ondersteund. 

© Primitieve contactdozen geven processen rechtstreekse toegang tot de proto- 
collen die de andere contactdoostypen ondersteunen. Zo zijn niet alleen proto- 
collen op het hoogste niveau toegankelijk, maar ook die op lagere niveaus. In 
het Internet-domein is het bijvoorbeeld mogelijk TCP te bereiken, IP daaron- 
der, of een Ethernet-protocol daar weer onder. Dit is nuttig voor het ontwik- 
kelen van nieuwe protocollen. 


De contactdoosvoorziening werkt met een groep specifieke systeemaanroe- 
pen. De contactdoos-systeemaanroep (socket) creëert een contactdoos. Als argu- 
menten accepteert deze de specificaties van het communicatiedomein, het type 
contactdoos en het protocol dat gebruikt dient te worden om dat type te onder- 
steunen. De waarde die wordt geretourneerd is een klein getal, dat contactdoos- 
beschrijver (Engels: socket descriptor) wordt genoemd. Dit valt in dezelfde naam- 
ruimte als de bestandsbeschrijvers. De contactdoosbeschrijver doet dienst als in- 
dex in de reeks van open ’bestanden’ in de g-structuur in de kern en heeft ook 
een bestandsstructuur toegewezen gekregen. De bestandsstructuur in 4.2BSD kan 
naar een contactdoosstructuur wijzen in plaats van naar een i-knooppunt. In dit 
geval wordt bepaalde informatie over de contactdoos (zoals het type, de berich- 
tenteller en de gegevens in zijn invoer- en uitvoer-wachtrijen) direct in de contact- 
doosstructuur bewaard. | 

Wil een ander proces de contactdoos adresseren, dan moet de contactdoos 
een naam hebben. Een naam wordt met de contactdoos verbonden door de bind- 
systeemaanroep, die de contactdoosbeschrijver accepteert, een wijzer naar de 
naam en de lengte van de naam in de vorm van een reeks bytes. De inhoud en 
lengte van de reeks bytes hangen af van het adresformaat. De connect-systeem- 
aanroep (verbind) wordt gebruikt om een verbinding te leggen. De argumenten 
zijn syntactisch gezien dezelfde als voor de bind; de contactdoosbeschrijver geeft 
de lokale contactdoos weer, terwijl het adres dat is van de niet-lokale contactdoos 
waarnaar men de verbinding probeert te leggen. 


14.9 Communicatie tussen processen 557 


Veel processen die met elkaar communiceren door middel van de contact- 
doos-vorm van communicatie tussen processen gaan te werk volgens het cliënt/ 
dienstverlener-model. In dit model verleent het dienstverlener-proces een dienst 
aan het cliënt-proces. Wanneer de dienst geleverd kan worden luistert het dienst- 
verlener-proces naar een bekend adres en gebruikt het cliënt-proces de connect, 
zoals hiervoor uiteengezet, om de dienstverlener te bereiken. 

Een dienstverlener-proces gebruikt de socket-systeemaanroep (contactdoos) 
om een contactdoos te creëren en bind om het reeds bekende adres van zijn dienst 
met zich te verbinden. Dan gebruikt het de listen-systeemaanroep (luister) om de 
kern mee te delen dat het klaar staat om verbindingen met cliënten aan te nemen 
en hoeveel nog niet tot stand gebrachte verbindingen de kern in de wachtrij moet 
zetten tot de dienstverlener ze moet gaan behandelen. Tenslotte gebruikt de 
dienstverlener de accept-systeemaanroep (accepteer) om de afzonderlijke verbin- 
dingen aan te nemen. Zowel listen als accept accepteren als argument de contact- 
doosbeschrijver van de oorspronkelijke contactdoos. Accept retourneert een nieu- 
we contactdoosbeschrijver die met de nieuwe verbinding overeenkomt; de oor- 
spronkelijke contactdoosbeschrijver blijft open voor verdere verbindingen. De 
dienstverlener maakt gewoonlijk gebruik van de Jork-systeemaanroep (vertak) om 
na de accept een nieuw proces te produceren om de cliënt te bedienen, terwijl 
het oorspronkelijke dienstverlener-proces doorgaat met luisteren of er nog meer 
verbindingen gelegd moeten worden. 

Er zijn ook systeemaanroepen voor het instellen van parameters van een 
verbinding en voor het retourneren van het adres van de niet-lokale contactdoos 
na een accept. 

Wanneer een verbinding voor een type contactdoos zoals een stroom-con- 
tactdoos wordt gelegd, zijn de adressen van beide eindpunten bekend en is er 
geen verdere adresinformatie nodig voor het overbrengen van de gegevens. De 
gewone read- en write-systeemaanroepen kunnen dan worden gebruikt voor het 
overbrengen van de gegevens. 

De eenvoudigste manier om een verbinding te beëindigen en de daarmee 
verbonden contactdoos op te heffen is het gebruik van de close-systeemaanroep 
(sluit) op de contactdoosbeschrijver ervan. Men kan ook slechts één communica- 
tierichting van een duplexverbinding willen beëindigen; in dat geval kan men de 
shutdown-systeemaanroep (zet stop) gebruiken. 

Sommige typen contactdozen, zoals datagram-contactdozen, ondersteunen 
geen verbindingen, maar in plaats daarvan wisselen hun contactdozen datagram- 
men uit die individueel geadresseerd moeten worden. De systeemaanroepen send- 
to en recvfrom (zend naar en ontvang van) worden voor zulke verbindingen ge- 
bruikt. Beide accepteren als argumenten een contactdoosbeschrijver, een buffer- 
wijzer en de lengte van de buffer, en een wijzer naar en de lengte van een adres- 
buffer. De adresbuffer bevat het adres waarnaar de sendto moet zenden en wordt 
gevuld met het adres van het datagram dat zojuist van de recvfrom ontvangen is. 
De hoeveelheid gegevens die feitelijk is overgebracht wordt door beide systeem- 
aanroepen geretourneerd. 
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De select-systeemaanroep (selecteer) kan worden gebruikt om met een mul- 
tiplexbewerking gegevens op verscheidene bestandsbeschrijvers en/of contact- 
doosbeschrijvers over te brengen. Deze aanroep kan zelfs worden gebruikt om 
één dienstverlener-proces de mogelijkheid te bieden te luisteren of er nog verbin- 
dingen met cliënten voor allerlei diensten gelegd moeten worden, en een proces 
te vertakken (fork) voor iedere verbinding wanneer deze wordt gelegd. Dit wordt 
bewerkstelligd door voor iedere dienst een contactdoos, bind en listen en vervol- 
gens een select op al de contactdoosbeschrijvers uit te voeren. Wanneer select 
activiteit op een beschrijver aangeeft, voert de dienstverlener er een accept op uit 
en vertakt het een proces op de nieuwe beschrijver die door de accept is geretour- 
neerd. Daarbij wordt het aan het ouderproces overgelaten opnieuw een select te 
doen. 


14.9.2 Netwerkondersteuning 


Bijna alle huidige Unix-systemen ondersteunen de UUCP-netwerkvoorzieningen, 
die het meest worden gebruikt bij telefoonkieslijnen ter ondersteuning van het 
UUCP-postnetwerk en het USENET-nieuwsnetwerk. Dit zijn echter in het gun- 
stigste geval rudimentaire netwerkvoorzieningen, daar deze zelfs geen logins op 
afstand (remote login’) ondersteunen, laat staan procedureaanroepen op afstand 
of gedistribueerde bestandssystemen. Deze voorzieningen zijn ook bijna volledig 
geïmplementeerd als gebruikersprocessen en maken geen deel uit van het eigenlij- 
ke besturingssysteem. 

42BSD ondersteunt de DARPA Internet-protocollen UDP, TCP, IP en 
ICMP, over een breed scala van Ethernet-, token-ring- en Arpanet-koppelingen. 
De structuur in de kern ter ondersteuning hiervan is bedoeld om de implementa- 
tie van verdere protocollen te vergemakkelijken, die alle toegankelijk zijn via de 
contactdooskoppeling. De eerste versie van de betrokken code werd door Rob 
Gurwitz van BBN geschreven als een extra pakket voor 4.1BSD. 

Het OSlI-referentiemodel (‘Open Systems Interconnection’) van de Organi- 
satie voor Internationale Standaards (‘International Standards Organisation’; 
ISO) voor het gebruik van netwerken schrijft zeven lagen netwerkprotocollen en 
strikte methoden voor de communicatie daartussen voor. Een implementatie van 
een protocol kan alleen communiceren met een gelijkwaardige entiteit die hetzelf- 
de protocol in dezelfde laag aanspreekt, of met met de protocol-protocolkop- 
peling met een protocol in de laag die in hetzelfde systeem daar onmiddellijk 
boven of onder ligt. 

De implementatie van het gebruik van netwerken in 4.2BSD, en tot op 
zekere hoogte de contactdoosvoorziening, is meer op het Arpanet Referentie Mo- 
del (ARM) georiënteerd. Het Arpanet in zijn oorspronkelijke vorm diende ervoor 
de werking aan te tonen van vele ideeén op het gebied van netwerken, zoals 
pakketschakeling en gelaagde protocollen. Vandaag de dag doet het dienst als 
een communicatiefaciliteit voor onderzoekers. Tezamen met de eraan verwante 
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netwerken in het DARPA Internet vormt het ook een experimenteer-omgeving 
voor onderzoek op het gebied van ‘gateways’ (speciale vorm van toegang tot net- 
werken). Het ARM is een voorloper van het ISO-model en het laatste werd weer 
grotendeels geïnspireerd door het Arpanet-onderzoek. 

Terwijl het ISO-model dikwijls wordt geïnterpreteerd als een model dat een 
limiet van één communicerend protocol per laag vereist, biedt ARM de mogelijk- 
heid van diverse protocollen in dezelfde laag. Er zijn slechts drie protocollagen 
in ARM: 


@ Processen/Toepassingen omspant de toepassings-, presentatie- en sessielagen 
van het ISO-model. Zulke programma’s op gebruikersniveau, zoals het be- 
standsoverdrachtprotocol (Engels: File Transfer Protocol of FTP) en Telnet 
(login op afstand), worden op dit niveau gevonden. 

@ Host-Host komt overeen met de transportlaag en het bovenste gedeelte van 
de netwerklagen van ISO. Zowel het Transmissiebesturingsprotocol (Engels: 
Transmission Control Protocol of TCP) en het Internet Protocol (IP) bevinden 
zich in deze laag, waarbij TCP boven IP ligt. TCP correspondeert met een ISO- 
Transportprotocol en IP verricht de addresseerfuncties van de netwerklaag in 
ISO. 

@ Netwerkkoppeling omspant het onderste gedeelte van de netwerklaag in ISO 
en de gehele gegevensverbindingslaag (Data Link layer”). De betrokken proto- 
collen hangen af van het fysieke type netwerk. Het Arpanet gebruikt de IMP- 
Host-protocollen, terwijl een Ethernet gebruik maakt van Ethernet-protocol- 
len. | 

@ Netwerkapparatuur. Het ARM heeft voornamelijk te maken met programma- 
tuur, zodat er niet expliciet een laag voor de netwerkapparatuur is. Elk werke- 
lijk netwerk zal echter apparatuur hebben die correspondeert met de appara- 
tuurlaag van ISO. 


De netwerkopzet in 4.2BSD is algemener dan zowel het ISO-model als het ARM, 
hoewel deze het dichtst bij de laatste komt. Zie figuur 14.11. 

Gebruikersprocessen communiceren met netwerkprotocollen (en dienten- 
gevolge met andere processen op andere machines) via de contactdoosvoorziening, 
die overeenkomt met de sessielaag in ISO, omdat deze verantwoordelijk is voor 
het opzetten en besturen van de communicatie. 

Contactdozen worden ondersteund door protocollen; waar mogelijk door 
verschillende protocollen die in lagen boven elkaar voorkomen. Een protocol 
kan diensten verlenen, zoals betrouwbare aflevering, onderdrukking van dubbele 
transmissies, besturing van de doorvoer, of adresseren, afhankelijk van het type 
contactdoos dat ondersteund wordt en de diensten die nodig zijn ten behoeve 
van hogere protocollen. 

Een protocol kan met een ander protocol communiceren of met de netwerk- 
koppeling die geschikt is voor de netwerkapparatuur. Er zijn in de algemene op- 
zet weinig beperkingen ten aanzien van welke protocollen met welke andere 
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Figuur 14.11 
Netwerk-referentiemodellen en hun lagen 


netwerkkoppeling 


protocollen kunnen communiceren, of ten aanzien van hoeveel protocollen boven 
elkaar gelaagd kunnen zijn. Het gebruikersproces kan, met gebruikmaking van 
het primitieve contactdoostype, rechtstreeks elke protocollaag benaderen, vanaf 
de bovenste die gebruikt wordt om een van de andere contactdoostypen, zoals 
stroomcontactdozen, te ondersteunen tot en met een primitieve netwerkkop- 
peling. Deze functie wordt gebruikt door routebepaling-processen en ook voor 
de ontwikkeling van nieuwe protocollen. 

Gewoonlijk heeft men één stuurroutine voor de netwerkkoppeling voor elk 
type netwerkbesturingseenheid. De netwerkkoppeling is verantwoordelijk voor 
het behandelen van zaken die karakteristiek zijn voor dit specifieke lokale net- 
werk. Dit gebeurt op zo’n manier dat de protocollen die van de koppeling gebruik 
maken zich daar niet om hoeven te bekommeren. 

De functies van de netwerkkoppeling hangen grotendeels af van de appara- 
tuur van het netwerk, dat wil zeggen: wat er voor het netwerk waarmee het is 
verbonden nodig is. Sommige netwerken kunnen betrouwbare transmissie op dit 
niveau ondersteunen, maar de meeste doen dat niet. Sommige leveren adressen 
voor de gegevensverspreiding, maar vele doen dat niet. 

Er zijn enkele projecten bij diverse organisaties aan de gang om andere dan 
de DARPA Internet-protocollen te implementeren, met inbegrip van de proto- 
collen die ISO tot nu toe ten gerieve van het OSI-model heeft gevolgd. 

De contactdoosvoorziening en de netwerkopzet gebruiken een gemeen- 
schappelijke groep geheugenbuffers, ofwel mbufs (memory buffers’). Deze heb- 
ben een middelgrote omvang die inligt tussen de grote buffers die door het blok- 
I/O-systeem worden gebruikt en de C-lijsten die door de tekengeoriénteerde 
randapparaten worden gebruikt. Een mbuf is 128 bytes lang, waarvan 112 bytes 
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voor gegevens gebruikt kunnen worden; de rest wordt gebruikt voor wijzers om 
de mbuf in wachtrijen te schakelen en om aan te geven hoeveel van de gegevens 
feitelijk in gebruik is. 

Gegevens worden gewoonlijk doorgegeven van laag naar laag (contact- 
doos/ protocol, protocol/ protocol, of protocol/ netwerkkoppeling) in mbufs. Deze 
mogelijkheid de buffers die de gegevens bevatten door te geven elimineert een 
portie kopiëren van gegevens, maar het is nog steeds nodig om kopgedeelten van 
buffers te verwijderen of toe te voegen. Het is ook voor vele doeleinden gemakke- 
lijk en efficiënt gegevens te kunnen bewaren van de omvang van de pagina zoals 
het geheugenbeheer die kent. Op deze wijze is het mogelijk dat de gegevens van 
een mbuf niet in de mbuf zelf, maar ergens anders in het geheugen verblijven. 
Voor dit doel is er een mbuf-paginatabel, evenals een pot van pagina’s die uitslui- 
tend voor mbuf-gebruik bestemd zijn. 


14.10 Samenvatting 


Unix werd in de Bell Laboratories ontwikkeld als een onderzoeksproject. Zoals 
het gedurende de laatste vijftien jaar veranderde, is het een belangrijk en krachtig 
besturingssysteem geworden. Er bestaan vele versies van Unix. 4.2BSD werd in 
Berkeley voor de VAX ontwikkeld, maar is naar vele andere computersystemen 
overgebracht. 

Unix biedt een bestandssysteem met adresboeken in een boomstructuur. 
Bestanden worden door de kern ondersteund als ongestructureerde reeksen bytes. 
Directe toegang en sequentiële toegang worden ondersteund met behulp van sys- 
teemaanroepen en bibliotheekroutines. 

Bestanden worden opgeslagen als een reeks gegevensblokken van een vaste 
omvang, met misschien nog een staartfragment. De gegevensblokken worden ge- 
vonden door middel van wijzers in het i-knooppunt. Adresboekingangen wijzen 
naar i-knooppunten. Schijfruimte wordt uit cilindergroepen toegewezen om de 
beweging van de magneetkop tot een minimum te beperken en het prestatiever- 
mogen te verbeteren. 

Unix is een systeem met multiprogrammering. Processen kunnen gemakke- 
lijk nieuwe processen in het leven roepen met behulp van de fork-systeemaanroep 
(vertak). Processen kunnen communiceren door middel van pijpen, of algemener, 
door middel van contactdozen (’sockets’). 

Processen worden gerepresenteerd door twee structuren: de processtructuur 
en de gebruikersstructuur. CVE-werkindeling gebeurt volgens een prioriteitsal- 
goritme met dynamisch berekende prioriteiten, wat in het uiterste geval neerkomt 
op werkindeling bij toerbeurt (round robin’). 

Het geheugenbeheer in 4.2BSD bestaat uit programmaverwisseling onder- 
steund door paginering. Een pagineerdemon-proces maakt gebruik van een ge- 
wijzigd *tweede-kans’-algoritme voor paginavervanging met het doel genoeg vrije 
kaders te houden om de processen in uitvoering te ondersteunen. 
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Pagineer- en bestands-I/O gebruiken een blok-buffertussengeheugen om de 
hoeveelheid werkelijke I/O zo klein mogelijk te houden. Terminals gebruiken een 
afzonderlijk systeem voor het bufferen van tekens. 

4.2BSD biedt een grote mate van netwerkondersteuning. Het contactdoos- 
begrip levert het programmeermechanisme voor het benaderen van andere 
processen, zelfs via een netwerk. Contactdozen worden ondersteund door diverse 
protocollen. 
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15 


HISTORISCH PERSPECTIEF 


In hoofdstuk 1 hebben we een kort historisch overzicht gegeven van de ontwikke- 
ling van besturingssystemen. Dat overzicht was kort en zonder veel details, omdat 
de fundamentele begrippen van besturingssystemen (CVE-werkindeling, geheu- 
genbeheer, processen, enzovoort) nog niét aan de orde waren geweest. Tegen de 
tijd echter dat we aan het eind van hoofdstuk 13 waren gekomen, werden de 
basisbegrippen goed begrepen. Zo waren we in staat te onderzoeken hoe onze 
begrippen in een werkelijk besturingssysteem, Unix, zijn toegepast. 

In dit hoofdstuk bespreken we in het kort verschillende andere invloedrijke 
besturingssystemen. Sommige daarvan (zoals het XDS-940 of het THE-systeem) 
waren systemen waarvan er maar één bestaat; andere (zoals OS/ 360) worden 
wijd en zijd gebruikt. De volgorde van de presentatie is zó gekozen dat de over- 
eenkomsten en verschillen tussen de systemen worden benadrukt en is niet strikt 
chronologisch of op grond van belangrijkheid. De serieuze student die besturings- 
systemen bestudeert moet met al deze systemen vertrouwd zijn. 

De behandeling van elk systeem is nog steeds erg kort, maar iedere para- 
graaf bevat verwijzingen voor verdere studie. De artikelen geschreven door de 
ontwerpers van de systemen zijn belangrijk zowel wegens hun technische inhoud 
als, wat misschien belangrijker is, wegens hun stijl en karakter. Dit hoofdstuk is 
enigszins een Bibliografie voor het gehele boek. 


15.1 Atlas 


Het Atlas-besturingssysteem [Kilburn et al. 1961, Howart et al. 1961, Fothering- 
ham 1961, Kilburn et al. 1962, Morris et al. 1962] werd ontworpen op de Univer- 
siteit van Manchester in Engeland aan het eind van de jaren ’50 en het begin van 
de jaren ’60. Veel van zijn fundamentele voorzieningen, die toen heel nieuw en 
baanbrekend waren, zijn standaardonderdelen van moderne besturingssystemen 
geworden. Stuurprogramma’s voor randapparatuur vormden een belangrijk on- 
derdeel van het systeem. Bovendien werden er systeemaanroepen aan toegevoegd | 


15.1 Atlas 565 


via een groep speciale instructies die de naam kregen van ‘extra codes’. 

Atlas was een besturingssysteem voor groepsgewijze verwerking (batch) met 
spool-verwerking. Spool-verwerking maakte het mogelijk dat het systeem de 
werkindeling voor jobs deed in overeenstemming met de beschikbaarheid van 
randapparaten, zoals magneetbandeenheden, ponsbandlezers, ponsbandponsers, 
regeldrukkers, kaartlezers of kaartponsmachines. 

De opmerkelijkste voorziening van Atlas was echter het geheugenbeheer. 
Kernengeheugen was erg nieuw en in die tijd erg duur. Veel computers, zoals 
de IBM 650, gebruikten een trommel als primair geheugen. Het Atlas-systeem 
gebruikte een trommel als hoofdgeheugen, maar had een kleine hoeveelheid ker- 
nengeheugen die als een tussengeheugen voor de trommel werd gebruikt. Pagine- 
ren op verzoek werd gebruikt om automatisch informatie tussen het kernengeheu- 
gen en de trommel over te brengen. 

Het Atlas-systeem maakte gebruik van een Ferranti-computer met woorden 
van 48 bits. De adressen waren opgebouwd uit 24 bits, maar deze werden de- 
cimaal gecodeerd zodat slechts 1.000.000 woorden geadresseerd konden worden. 
Voor die tijd was dit een zeer grote adresruimte. Het fysieke geheugen voor Atlas 
was een trommel van 98K woorden en 16K woorden kernengeheugen. Het geheu- 
gen was verdeeld in pagina’s van 512 woorden, die 32 kaders in het fysieke geheu- 
gen opleverden. Met behulp van een associatief geheugen van 32 registers was de 
vertaling van een virtueel naar een fysiek adres geïmplementeerd. 

Trad er een paginafout op, dan werd een algoritme voor paginavervanging 
opgeroepen. Eén geheugenkader werd altijd leeg gehouden, zodat een overbren- 
ging van de trommel onmiddellijk kon starten. Het algoritme voor paginavervan- 
ging probeerde het toekomstige gedrag van geheugentoegang te voorspellen op 
grond van het gedrag in het verleden. Een referentiebit voor elk kader werd aan- 
gezet telkens wanneer toegang tot het kader plaatsvond. Na elke 1024 instructies 
werden de referentiebits in het geheugen ingelezen. De laatste 32 waarden van 
de referentiebit werden gebruikt om de tijd te definiëren die verstreken is sinds 
de laatste verwijzing (ti) en het tijdsinterval tussen de laatste twee verwijzingen 
(t2). Pagina's werden dan voor vervanging gekozen in de volgende volgorde: 


l. Elke pagina waarvoor ti > t + 1. Deze pagina wordt niet langer als in ge- 
bruik beschouwd. 

2. Als voor alle pagina’s geldt: ti < tz, vervang dan de pagina met de grootste 
waarde voor t2 — tı. 


Het algoritme voor paginavervanging gaat ervan uit dat programma’s het geheu- 
gen volgens lussen adresseren. Als de tijd tussen de laatste twee verwijzingen t2 
is, wordt een volgende verwijzing tz tijdseenheden later verwacht. Als er geen 
verwijzing plaatsvindt (ti > tz), wordt aangenomen dat de pagina niet langer 
gebruikt wordt en wordt deze vervangen. Zijn alle pagina’s nog steeds in gebruik, 
dan wordt de pagina die gedurende de langste tijd niet nodig zal zijn vervangen. 
De verwachte tijd tot de volgende verwijzing is t2 — ti. 
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15.2 XDS-940 


Het XDS-940 besturingssysteem [Lichtenberger en Pirtle 1965, Lampson et al. 
1966] werd aan de Universiteit van Californië in Berkeley ontworpen. Evenals 
het Atlas-systeem gebruikte het paginering voor het geheugenbeheer. In tegen- 
stelling tot het Atlas-systeem was XDS-940 een systeem met tijddeling. 

Pagineren werd alleen voor verplaatsing gebruikt, niet voor pagineren op 
verzoek. Het virtueel geheugen van ieder gebruikersproces bestond slechts uit 
16K woorden, terwijl het fysieke geheugen uit 64K woorden bestond. Pagina’s 
waren elk 2K woorden groot. De paginatabel werd in registers bewaard. Aange- 
zien het fysieke geheugen groter was dan het virtuele geheugen, konden verschil- 
lende gebruikersprocessen tegelijkertijd in het geheugen zijn. Het aantal gebrui- 
kers kon worden verhoogd door gemeenschappelijk gebruik van pagina’s wan- 
neer deze alleen-uitleesbare, herbetreedbare code bevatten. Processen werden op 
een trommel bewaard en door procesverwisseling al naar dat nodig was uit het 
geheugen gezet en weer daarin teruggebracht. 

Het XDS-940 systeem werd gebouwd uit een gewijzigd XDS-930 systeem. 
De wijzigingen waren kenmerkend voor de veranderingen die in een basiscom- 
puter werden aangebracht om het mogelijk te maken dat een besturingssysteem 
op de juiste wijze geschreven werd. Een gebruiker / monitor-modus werd toege- 
voegd. Bepaalde instructies, zoals I/O en Halt, werden als bevoorrechte instruc- 
ties gedefinieerd. Een poging om in de gebruiker-modus een bevoorrechte in- 
structie uit te voeren liep in de ’val’ van het besturingssysteem. 

Aan de instructiegroep behorende tot de gebruiker-modus werd een sys- 
teemaanroep (SYSPOP) toegevoegd . Deze instructie werd gebruikt om nieuwe 
systeemelementen, zoals bestanden, te creëren, waarbij het aan het besturingssys- 
teem werd overgelaten de fysieke systeemelementen te beheren. Bestanden wer- 
den bijvoorbeeld toegewezen in blokken van 256 woorden op de trommel. Een 
bittabel werd gebruikt om vrije blokken op de trommel te beheren. Elk bestand 
had een indexblok met wijzers naar de feitelijke gegevensblokken. Indexblokken 
waren aan elkaar geketend. 

Het XDS-940 systeem voorzag ook in systeemaanroepen die het processsen 
mogelijk maakten subprocessen te creëren, te starten, op te schorten en op te 
heffen. Een gebruiker-programmeur kon een systeem van processen opbouwen. 
Afzonderlijke processen konden ten behoeve van communicatie en synchronisa- 
tie gemeenschappelijk gebruik van het geheugen maken. Bij het creëren van een 
proces wordt een boomstructuur gedefinieerd, waarbij een proces de wortel is en 
zijn subprocessen de knooppunten daaronder in de boom. Elk van de subproces- 
sen kon op zijn beurt ook weer andere subprocessen creëren. 


15.3 THE 


Het THE-besturingssysteem [Dijkstra 1968a, Bron 1972, McKeag en Wilson 
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1976 (hoofdstuk 3)] werd aan de Technische Hogeschool (tegenwoordig: Techni- 
sche Universiteit) in Eindhoven ontworpen. Het is een systeem voor groepsgewij- 
ze verwerking dat draaide op een computer van Nederlandse makelij (Philips- 
Electrologica), de EL X8, die 32K woorden van 27 bits heeft. Het systeem was 
voornamelijk bekend om zijn zuivere ontwerp, met name zijn gelaagde structuur, 
en het gebruik van een groep parallelle processen die voor hun synchronisatie 
van semaforen gebruik maakten. 

In tegenstelling tot het XDS-940 systeem was de groep processen in het 
THE-systeem evenwel statisch. Het besturingssysteem zelf werd ontworpen als 
een groep samenwerkende processen. Daarnaast werden vijf gebruikersprocessen 
gecreëerd, die dienst deden als actieve instrumenten voor het compileren, uitvoe- 
ren en afdrukken van gebruikersprogramma’s. Wanneer de ene job klaar was ging 
het proces terug naar de invoer-wachtrij, zodat een andere job geselecteerd kon 
worden. 

Er werd gebruik gemaakt van een algoritme voor CVE-werkindeling dat op 
prioriteit gebaseerd was. De prioriteiten werden na iedere twee seconden opnieuw 
berekend; ze waren omgekeerd evenredig met de hoeveelheid CVE-tijd die kort 
geleden (in de laatste acht tot tien seconden) gebruikt was. Deze opzet gaf een 
hogere prioriteit aan I/O-gebonden processen en aan nieuwe processen. 

Het geheugenbeheer was beperkt door het gebrek aan ondersteuning door 
de apparatuur. Er werd echter een pagineringsmethode met behulp van de pro- 
grammatuur gebruikt, omdat het systeem heel beperkt was en gebruikerspro- 
gramma's alleen in ALGOL geschreven konden worden. Het ALGOL-vertaal- 
programma genereerde automatisch aanroepen van systeemroutines, waardoor 
het zeker was dat de verlangde informatie zich in het geheugen bevond, indien 
nodig door programmaverwisseling. Het reservegeheugen was een trommel met 
512K woorden. De paginagrootte was 512 woorden en de strategie voor pagina- 
vervanging was MRG (Minst-Recent-Gebruikt). 

Een ander onderdeel waaraan in het THE-systeem grote zorg was besteed 
was de behandeling van impasses. Het bankiersalgoritme werd gebruikt voor het 
vermijden van impasses. 

Nauw verwant aan het THE-systeem is het Venus-systeem [Liskov 1972a]. 
Het Venus-systeem was ook ontworpen met een gelaagde structuur en maakte 
gebruik van semaforen om processen te synchroniseren. De lagere ontwerp- 
niveaus waren echter in de microcode geimplementeerd, waardoor een veel snel- 
ler systeem ontstond. Het geheugenbeheer werd gewijzigd in deze zin dat het 
geheugen zowel in pagina’s als in segmenten verdeeld was (gepagineerde segmen- 
tering). Het systeem werd ook meer als een systeem met tijddeling ontworpen 
dan als een systeem voor groepsgewijze verwerking. 


15.4 RC 4000 


Het RC 4000 systeem was, evenals het THE-systeem, voornamelijk bekend we- 
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gens de ontwerpideeën die erin vervat waren. Het werd ontworpen voor de Deen- 
se RC 4000 computer door Regenecentralen, met name door Brinch Hansen 
[1970, 1973a (hoofdstuk 8)]. Het doel was niet een systeem voor groepsgewijze 
verwerking, of een systeem met tijddeling, of enig ander specifiek systeem te 
ontwerpen. Het doel was eerder een nucleus voor een besturingssysteem te schep- 
pen, ofwel een kern, waarop anderen een volledig besturingssysteem zouden kun- 
nen bouwen [Lauesen 1975]. Op deze wijze was de systeemstructuur gelaagd en 
werden alleen de lagere niveaus, de kern, geleverd. 

De kern ondersteunde een verzameling parallelle processen. Processen wer- 
den ondersteund door een CVE-werkindeling bij toerbeurt (round robin’). Al 
konden processen gemeenschappelijk gebruik van het geheugen maken, het 
primaire mechanisme voor communicatie en synchronisatie was het berichtensys- 
teem dat door de kern geleverd werd. Processen kunnen met elkaar communi- 
ceren door berichten met een vaste lengte van acht woorden uit te wisselen. Alle 
berichten worden opgeslagen in buffers die komen uit een gemeenschappelijke 
bufferpot. Wanneer een berichtenbuffer niet langer nodig is, wordt deze aan de 
gemeenschappelijke bufferpot teruggegeven. | 

Met ieder proces is een berichten-wachtrij verbonden. Deze bevat al de be- 
richten die naar dat proces verstuurd maar nog niet ontvangen zijn. Berichten 
worden in FIFO-volgorde (Eerst-In-Eerst-Uit) uit de wachtrij gehaald. Het sys- 
teem ondersteunt vier elementaire bewerkingen, die atomisch worden uitgevoerd: 


@ zend-bericht (in ontvanger, in bericht, uit buffer). 

@ wacht-bericht (uit afzender, uit bericht, uit buffer). 
@ zend-antwoord (uit resultaat, in bericht, in buffer). 
@ wacht-antwoord (uit resultaat, uit bericht, in buffer). 


De laatste twee bewerkingen stellen processen in staat verschillende berichten 
tegelijk uit te wisselen. 

Deze elementaire functies vereisen dat een proces zijn berichten-wachtrij 
op FIFO-volgorde bedient en dat het zichzelf blokkeert terwijl andere processen 
zijn berichten aan het afhandelen zijn. Om deze beperkingen op te heffen worden 
er twee extra communicatiefuncties geleverd. Deze maken het mogelijk dat een 
proces wacht op de aankomst van het volgende bericht of antwoord en dat het 
zijn wachtrij in elke volgorde bedient: 


@ wacht-gebeurtenis (in vorige-buffer, uit volgende-buffer, uit resultaat). 
@ haal-gebeurtenis-op (uit buffer). 


Randapparaten werden ook als processen behandeld. De stuurporgramma’s voor 
de randapparatuur bestonden uit code die de onderbrekingen door het randappa- 
raat en de registerinhouden omzette in berichten. Op die manier schreef een pro- 
ces naar een terminal door daarnaar een bericht te sturen. Het betreffende stuur- 
programma ontving het bericht en voerde het teken dan uit naar de terminal. 
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Een invoerteken onderbrak dan het systeem, waarna de besturing werd overge- 
dragen aan een stuurprogramma voor de terminal. Het stuurprogramma creëerde 
een bericht uit het invoerteken en zond dit dan aan het wachtende proces. | 

Brinch Hansen heeft zijn werk aan besturingssystemen, speciaal de prin- 
cipes van het ontwerpen van besturingssystemen, voortgezet. De taal Concurrent 
Pascal [Brinch Hansen 1975] werd gedefinieerd om het schrijven van een bestu- 
ringssysteem in een hogere programmeertaal mogelijk te maken. Men heeft Con- 
current Pascal gebruikt om het Solo-besturingssysteem te definiëren [Brinch 
Hansen 1977]. 

Solo is een besturingssysteem voor één gebruiker met multiprogrammering 
voor de PDP-11/45. Het bestaat uit een verzameling van parallelle processen. 
Het belangrijkste aspect van het Solo-systeem is dat het gebruik van een hogere 
programmeertaal het mogelijk maakte dat het gehele systeem door twee mensen 
in minder dan een jaar werd geprogrammeerd. Het systeem is voldoende compact 
om als voorbeeld in een cursus besturingssystemen te worden bestudeerd. 


15.5 CTSS 


Het CTSS-systeem (Compatibe Time-Sharing System) [Corbato et al. 1962, 
Crisman et al. 1964] werd op het MIT ontworpen als een experimenteel systeem 
met tijddeling. Het werd geïmplementeerd op een IBM 7090 en uiteindelijk on- 
dersteund voor maximaal 32 interactieve gebruikers. De gebruikers kregen een 
groep interactieve commando’s, die hen de mogelijkheid boden bestanden te be- 
werken en programma’s te compileren en te draaien vanaf een terminal. 

De 7090 had een geheugen van 32K, dat uit woorden van 36 bits bestond. 
De monitor gebruikte 5K woorden, zodat er 27K overbleef voor de gebruikers. 
Op gebruikers-geheugenbeelden werd programmaverwisseling toegepast tussen 
het hoofdgeheugen en een snelle trommel. De CVE-werkindeling maakte gebruik 
van een algoritme met een wachtrij met meerdere niveaus en terugkoppeling. Het 
tijd-quantum voor niveau i bedroeg 2i tijdseenheden. Als een programma zijn 
CVE-actie niet binnen één tijd-quantum afkreeg, werd het omlaag geschoven 
naar het volgende niveau van de wachtrij, zodat het tweemaal zoveel tijd kreeg. 
Het programma op het hoogste niveau (met het kortste quantum) werd het eerst 
gedraaid. Het beginniveau van een programma werd vastgesteld aan de hand van 
zijn grootte, zodat zijn tijd-quantum minstens even lang was als zijn program- 
maverwisselingstijd. 

CTSS had een buitengewoon groot succes en bleef zelfs tot 1972 in gebruik. 
Hoewel het heel beperkt was, slaagde het erin te demonstreren dat tijddeling 
een gemakkelijke en praktische werkwijze voor computerverwerking was. Eén 
resultaat van CTSS was de versnelde ontwikkeling van systemen met tijddeling. 
Een ander resultaat was de ontwikkeling van Multics. 
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15.6 Multics 


Multics werd op het MIT ontworpen [Corbato en Vyssotsky 1965, Daley en Den- 
nis 1968, Organick 1972, Corbato et al. 1972] als een natuurlijke uitbreiding van 
CTSS. CTSS en andere systemen uit de begintijd met tijddeling hadden zo’n 
succes dat dit onmiddellijk het verlangen teweeg bracht snel op grotere en betere 
systemen over te gaan. Toen grotere computers beschikbaar kwamen, begonnen 
de ontwerpers van CTSS aan het tot stand brengen van een functieprogramma 
voor tijddeling. Computer-dienstverlening zou zoiets moeten gaan worden als 
elektriciteitsvoorziening. Grote computersystemen zouden via telefoonlijnen met 
terminals in kantoren en huizen in een hele stad moeten worden verbonden. Het 
besturingssysteem zou een systeem met tijddeling zijn dat continu draaide met 
een enorm bestandssysteem van gemeenschappelijk gebruikte programma's en 
gegevens. 

Multics werd ontworpen door een team van het MIT, General Electric (dat 
later zijn computerafdeling aan Honeywell verkocht) en Bell Laboratories (dat 
in 1969 uit het project stapte). De GE 635 basiscomputer werd veranderd in een 
nieuw computersysteem, dat de GE 645 werd genoemd, in hoofdzaak door de 
toevoeging van geheugenapparatuur met gepagineerde segmentering. 

Er werd een virtueel adres samengesteld uit een segmentnummer van 18 
bits en een relatieve woordpositie van 16 bits. De segmenten zijn daarbij in pa- 
gina’s van 1K verdeeld. Er werd gebruik gemaakt van het tweede-kans’-algoritme 
voor paginavervanging. 

De gesegmenteerde virtuele adresruimte werd met het bestandssysteem sa- 
mengevoegd; elk segment was een bestand. Segmenten werden geadresseerd met 
behulp van de bestandsnaam. Het bestandssysteem zelf had een boomstructuur 
met meerdere niveaus, waardoor gebruikers de mogelijkheid hadden hun eigen 
subadresboekstructuren op te zetten. 

Evenals CTSS dat deed maakte Multics gebruik van een wachtrij met meer- 
dere niveaus en terugkoppeling voor CVE-werkindeling. Beveiliging werd gereali- 
seerd met behulp van een toegangslijst voor elk bestand en een groep van bevei- 
ligingsringen voor processen in uitvoering. Het systeem, dat bijna geheel in 
PL/I werd geschreven [Corbato 1969], bestond uit ongeveer 300.000 regels code. 
Het werd uitgebreid tot een multiprocessorsysteem, waarbij een CVE voor onder- 
houd uit de roulatie kon worden genomen terwijl het systeem toch bleef draaien. 


15.7 OS/360 


De langste ontwikkelingslijn van besturingssystemen is ongetwijfeld die voor de 
IBM-computers. De eerste IBM-computers, zoals de IBM 7090 en 7094, zijn de 
beste voorbeelden van de ontwikkeling van gemeenschappelijke subroutines voor 
I/O, gevolgd door een residente monitor, bevoorrechte instructies, geheugen- 
beveiliging en eenvoudige groepsgewijze verwerking. Deze systemen werden af- 
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zonderlijk ontworpen, dikwijls door iedere locatie onafhankelijk van de andere. 
Dit had tot gevolg dat IBM werd geconfronteerd met vele verschillende compu- 
ters, met verschillende talen en verschillende soorten systeemprogrammatuur. 

De IBM/360 werd ontworpen om in deze situatie verandering te brengen. 
De IBM/360 werd ontworpen als een familie van computers die de gehele scala 
omspande van kleine kantoormachines tot grote wetenschappelijke machines. 
Slechts één verzameling programmatuur zou voor deze systemen nodig zijn, die 
alle hetzelfde besturingssysteem gebruikten: OS/360 [Mealy et al. 1966]. Men 
ging ervan uit dat deze opzet de onderhoudsproblemen voor IBM zou terugdrin- 
gen en gebruikers in staat zou stellen om programma’s en toepassingen vrijelijk 
van het ene IBM-systeem naar het andere over te brengen. 

Helaas probeerde OS/360 alles voor iedereen te zijn. Dit had tot gevolg dat 
het niets van dat alles erg goed deed. Het bestandssysteem kende onder meer een 
type-veld dat het type van elk bestand definieerde; zo werden er verschillende 
bestandstypen gedefinieerd voor records met vaste en met variabele lengte, even- 
als voor geblokte en ongeblokte bestanden. Er werd aaneengesloten toewijzing 
gebruikt, zodat de gebruiker de grootte van ieder uitvoerbestand moest schatten. 
De Job-besturingstaal Job Control Language (JCL) was voor de gemiddelde ge- 
bruiker onbegrijpelijk, omdat er parameters voor elke denkbare optie aan waren 
toegevoegd. 

De routines voor het geheugenbeheer werden belemmerd door de architec- 
tuur. Hoewel de adressering gebruik maakte van een basisregister, kon het pro- 
gramma toegang krijgen tot het basisregister en dit wijzigen, zodat er door de 
CVE absolute adressen werden gegenereerd. Deze opzet maakte dynamische ver- 
plaatsing onmogelijk; het programma werd op het tijdstip dat het geladen werd 
aan het fysieke geheugen gebonden. Men produceerde twee afzonderlijke versies 
van het besturingssysteem: OS/MFT maakte gebruik van vaste partities en OS/ 
MVT gebruikte variabele regio’s. 

Het systeem was geschreven in assembleertaal door duizenden program- 
meurs, wat resulteerde in miljoenen regels code. Het besturingssysteem zelf ver- 
eiste al grote hoeveelheden geheugen voor zijn code en tabellen. De overhead van 
het besturingssysteem nam dikwijls al de helft van het totale aantal CVE-cycli in 
beslag. In de loop der jaren werden nieuwe versies uitgegeven waardoor nieuwe 
voorzieningen werden toegevoegd en fouten gecorrigeerd. De correctie van één 
fout veroorzaakte dikwijls een andere fout ergens in een totaal ander gedeelte 
van het systeem, zodat het aantal bekende fouten in het systeem zaten tamelijk 
constant was. 

Met de overgang naar de architectuur van de IBM 370 werd virtueel geheu- 
gen aan OS/360 toegevoegd. De eraan ten grondslag liggende apparatuur leverde 
een virtueel geheugen met gesegmenteerde paginering. Nieuwe versies van OS/ 
360 gebruikten deze apparatuur op verschillende manieren. OS/VS1 kwam met 
één grote virtuele adresruimte, waarin OS/MFT draaide. Op deze manier was 
het besturingssysteem zelf, evenals de gebruikersprogramma’s, gepagineerd. In 
OS/VS2 Release 1 draaide OS/MVT in het virtuele geheugen. Tenslotte gaf OS/ 
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VS2 Release 2, die nu MVS heet, elke gebruiker zijn eigen virtuele geheugen. 

MVS is in feite nog steeds een besturingssysteem voor groepsgewijze ver- 
werking. Het CTSS-systeem werd op een IBM 7094 gedraaid, maar het MIT 
besloot dat de adresruimte van de 360, IBM’s opvolger van de 7094, te klein was 
voor Multics, zodat zij op een andere fabrikant overgingen. IBM besloot toen 
zijn eigen systeem met tijddeling te maken, TSS/360 [Comfort 1965, Lett en Ko- 
nigsford 1968]. TSS/360 moest, evenals Multics, een groot functieprogramma 
met tijddeling worden. De 360-basisarchitectuur werd in het model 67 zodanig 
gemodificeerd dat het virteel geheugen verschafte. Diverse locaties kochten de 

360/67 met het oog op het komende TSS/360. 

TSS/360 ondervond evenwel vertraging [Schwemm 1972]; daarom werden 
er andere systemen met tijddeling ontwikkeld als tijdelijke systemen totdat TSS/ 
360 beschikbaar zou zijn. Een tijddelingsoptie (Time Sharing Option; TSO) werd 
aan OS/360 toegevoegd. Het Cambridge Scientific Center van IBM ontwikkelde 
CMS als een systeem voor één gebruiker en CP/67 als een virtuele machine om 
CMS op te draaien [Meyer en Seawright 1970, Parmelee et al. 1972]. De Universi- 
teit van Michigan ontwikkelde het Michigan Terminal System (MTS) [Alexander 
1972]; Stanford ontwikkelde Wylbur [Fajman 1973). 

Toen TSS/360 eindelijk uitkwam was het een fiasco. Het was te groot en 
te langzaam. Daarom wilde geen enkele locatie van zijn tijdelijke systeem over- 
schakelen op TSS/360. Vandaag de dag wordt tijddeling op IBM-systemen voor- 
namelijk geboden door TSO onder MVS, of door CMS onder CP/67 (dat nu VM 
heet). 

Wat ging er mis met TSS/360 en Multics? Eén kant van het probleem was 
dat dit werkelijk heel geavanceerde systemen waren die te groot en te complex 
waren om echt begrepen te worden. Een ander probleem was de veronderstelling 
dat computercapaciteit beschikbaar zou zijn op een grote computer in een andere 
locatie door middel van tijddeling. Nu blijkt dat de meeste computerverwerking 
zal gaan plaatsvinden door kleine machines voor persoonlijk gebruik — personal 
computers — en niet door een groot systeem met tijddeling dat ergens anders 
staat opgesteld met de bedoeling dat zo’n systeem alles voor alle gebruikers is. 


15.8 Andere systemen 


Natuurlijk bestaan er nog andere besturingssystemen, waarvan de meeste wel 
enige interessante eigenschappen hebben. Het MCP-besturingssysteem voor de 
computerserie van Burroughs [McKeag en Wilson 1976] was het eerste dat in een 
systeemprogrammeertaal geschreven werd. Het ondersteunde ook segmentering 
en meer dan één CVE. Het SCOPE-besturingssysteem voor de CDC 6600 
[McKeag en Wilson 1976] was eveneens een systeem voor meerdere CVE's. Het 
coördineren en synchroniseren van meerdere processen was verrassend goed ont- 
worpen. Tenex [Bobrow et al. 1972] was een van de eerste systemen met pagine- 
ren op verzoek voor de PDP-10, dat grote invloed heeft gehad op daarop volgen- 
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de systemen met tijddeling, zoals TOPS-20 voor de DEC-20. Het VMS-bestu- 
ringssysteem voor de VAX is gebaseerd op het RSX-besturingssysteem voor de 
PDP-11. CP/M is het meest gebruikte besturingssysteem voor 8-bits microcom- 
putersystemen, terwijl MS-DOS het meest voorkomende systeem is voor 16-bits 
microcomputers. 
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Woordenlijst Engels-Nederlands 


abnormal termination voortijdige beëindi- 
ging 

abort (to) voortijdig beëindigen 

aborted execution voortijdig beëindigde uit- 
voering 

abstract data type abstract gegevenstype 

access toegang 

access (to) benaderen 

access control toegangsbesturing, toegangs- 
regulatie 

access matrix toegangsmatrix 

access method toegangsmethode 

access right toegangsrecht 

access right expression toegangsrecht-ex- 
pressie 

accounting boekhouding, doorbelasting, fi- 
nanciële administratie 

acquire (to) verkrijgen 

acyclic graph acyclische graaf, graaf zonder 
lussen 

acyclic graph directory adresboek met acy- 
clische-graafstructuur 

address adres 

address (to) adresseren 

addressing error adresseerfout 

addressing mode adresseer-modus 

address mapping adresvertaling 

address protection adresbeveiliging 

address space adresruimte 

address translation adresvertaling 

allocation toewijzing 

allocation method toewijzingsmethode 

amplification uitbreiding 

append (to) (achteraan) toevoegen 

application toepassing 

application program toepassingsprogramma 

array reeks, array 

assembler assembleerprogramma, vertaal- 
programma, vertaler 

assembly language assembleertaal 

associative memory associatief geheugen 

associative register associatief register 

await (to) afwachten 


background job achtergrond-job 

backing store reservegeheugen, achtergrond- 
geheugen, extern geheugen 

backup copy reservekopie 

backup store reservegeheugen, achtergrond- 
geheugen, extern geheugen 

banker’s algorithm bankiersalgoritme 

bare machine kale machine 

base/limit registers basis- en limietregister 

base register basisregister 

basic file system basisbestandssysteem 

batch groep 

batch processing groepsgewijze verwerking 

batch system systeem voor groepsgewijze 
verwerking, batch-systeem 

best fit best-passend 

bidirectional communication link tweeweg- 
communicatieverbinding 

binary binair 

binary search binaire zoekmethode 

bind (to) koppelen 

bit map bittabel 

bit table bittabel 

bit vector bitvector 

block blok, fysiek record 

blocked state geblokkeerde toestand 

blocking indeling in blokken 

block size blokgrootte 

body romp(code) 

boolean booleaanse (variabele) 

boolean condition booleaanse voorwaarde 

boolean expression booleaanse expressie 

boolean variable booleaanse variabele 

bootstrap program zelfstartprogramma 

bounded-buffer problem begrensde-buffer- 
probleem 

bounded waiting gelimiteerd wachten 

bounds registers grensregisters 

buffer cache memory buffer-tussengeheugen 

buffering gebruik van buffers, buffering 

bus hoofdtransmissielijn, bus 

busy bezig, in gebruik 

busy waiting wachten-in-een-lus, wachtlus 


cache memory tussengeheugen 

call aanroep 

call (to) aanroepen 

capability functie, beschikkingsrecht 

capacity capaciteit, vermogen 

card image kaartbeeld 

card reader kaartlezer 

carry bit overdrachtsbit 

Central Processing Unit (CPU) 
centrale verwerkingseenheid, CVE 

central processor centrale verwerkingseen- 
heid 

channel kanaal 

channel program kanaalprogramma 

checkpoint controlepunt 

circuit switching circuitschakeling, doorkie- 
zen 

circular queue rondlopende wachtrij 

circular wait wachten-in-een-kring 

claim (to) vorderen 

close (to) sluiten 

collision detection ontdekken van botsingen 

command commando, opdracht 

command interpreter commandovertolker 

command language commandotaal 

command language interpreter commando- 
taalvertolker 

command line commandoregel 

common routines gemeenschappelijke rou- 
tines 

communication communicatie, berichtenver- 
keer 

communication facility communicatie- 
voorziening 

communication line communicatielijn 

communication link communicatieverbin- 
ding, communicatie(verbindings)lijn 

communication message system systeem 
voor berichtenverkeer 

communication network communicatienet- 
werk 

communication processor communicatie- 
processor 

communication system communicatiesys- 
teem 

compaction comprimering, verdichting 

compiler compileerprogramma, 
vertaalprogramma, vertaler 

concurrency gelijktijdigheid, simultane ver- 
werking, parallelverwerking, parallellisme 

concurrent gelijktijdig, simultaan, parallel 

concurrent language parallel-programmeer- 
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taal 

concurrent processes parallelle processen 

concurrent programming parallel-program- 
mering 

concurrent programming language parallel- 
programmeertaal 

concurrent statement parallel-opdracht 

conditional critical region voorwaardelijke 
kritieke regio 

conditional wait voorwaardelijk wachten 

condition code resultaatcode 

condition variable conditievariabele 

connected star network netwerk met sterver- 
binding 

connection strategy verbindingsstrategie 

console bedieningspaneel 

console command commando voor het bedie- 
ningspaneel 

console command interpreter vertolker van 
commando’s voor het bedieningspaneel 

console command processor verwerkings- 
programma van commando’s voor het be- 
dieningspaneel 

construct constructie, concept 

contention wedijver 

context switch contextomschakeling 

contiguous allocation aaneengesloten toe- 
wijzing 

contiguous disk space aaneengesloten schijf- 
ruimte 

control access right recht van regulatie van 
het toegangsrecht 

control card besturingskaart 

control card interpreter besturingskaartver- 
tolker 

convenience gebruiksgemak 

cooperating sequential processes samenwer- 
kende sequentiële processen 

copy access right recht van kopiëren van het 
toegangsrecht 

counter teller 

CPU (Central Processing Unit) centrale ver- 
werkingseenheid, CVE 

CPU-bound door de CVE begrensd, CVE- 
gebonden 

CPU burst CVE-actie 

CPU-I/O-burst cycle CVE-I/O-actiecyclus 

CPU protection CVE-beveiliging 

CPU response time CVE-reponstijd 

CPU scheduling CVE-werkindeling 

CPU scheduling algorithm algoritme voor 
CVE-werkindeling 
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CPU throughput doorvoercapaciteit van de 
CVE 

CPU turnaround time CVE-turnaround-tijd 

CPU utilization CVE-gebruiksfactor 

CPU waiting time CVE-wachttijd 

crash beschadiging, systeemstoring 

create (to) a file een bestand (aan)maken 

create (to) a process een proces in het leven 
roepen 

critical region kritieke regio 

critical section kritieke sectie 

current directory actief adresboek, lopend 
adresboek 

cycle cyclus, lus 

cycle detection opsporen van een lus 

cylinder cilinder 


dangling pointer in de lucht hangende wijzer 

data gegeven(s) 

data base database, gegevensbank 

data compaction comprimering van gegevens 

datalink gegevensverbindingslijn 

deadlock impasse 

deadlock avoidance vermijden van impasses 

deadlock detection opsporen van een impasse 

deadlock prevention voorkómen van impas- 
ses 

deadlock recovery oplossen van een impasse 

deadly embrace impasse 

dedicated voor speciale toepassingen 

default door het systeem gekozen waarde, 
default 

degree of multiprogramming multiprogram- 
meringsniveau 

delete (to) a file een bestand opheffen 

demand paging pagineren op verzoek 

demand segmentation segmenteren op ver- 
zoek 

device randapparaat 

device directory randapparaatadresboek 

device driver stuurroutine/programma voor 
randapparatuur 

device independence randapparaat-onaf- 
hankelijkheid 

device interrupt onderbreking door een rand- 
apparaat 

device management randapparatuurbeheer 

device queue randapparaat-wachtrij 

device status randapparaat-status 

device status table randapparaat-statustabel 

dining philosophers problem probleem van 
de tafelende filosofen 


direct access directe toegang 

direct access file direct-toegankelijk bestand 

direct access memory direct-toegankelijk ge- 
heugen 

directory adresboek 

directory entry adresboekingang 

directory file adresboekbestand 

directory file system adresboekbestands- 
systeem 

directory system adresboeksysteem 

dirty bit mutatiebit 

disk schijf, schijvengeheugen 

disk drive schijfaandrijfeenheid 

diskette diskette, floppy 

disk head /ees/schrijfkop 

disk pack schijvenpakket 

disk scheduling schijf-werkindeling 

disk space schijfruimte 

disk space allocation toewijzing van schijf- 
ruimte 

disk unit schijfeenheid 

dispatcher verdeelprogramma 

dispatching selectie voor verwerking 

distributed gedistribueerd, gespreid 

distributed system gedistribueerd systeem 

domain domein 

domain switching overschakelen op een an- 
der domein 

double buffering gebruik van twee buffers 

double-density met dubbele dichtheid 

drive aandrijfeenheid 

driver stuurroutine/programma 

drum trommel(geheugen) 

dump geheugenafdruk, dump 

dynamic loading dynamisch laden 

dynamic protection dynamische beveiliging 

dynamic relocation dynamische verplaatsing 

dynamic storage allocation dynamische ge- 
heugentoewijzing 


editing tekstopmaak 

editor tekstopmaakprogramma 

effective access time effectieve toegangstijd 
election algorithm verkiezingsalgoritme 
elegant degradation elegante degradatie 
encript (to) coderen | 

entry ingang 

entry procedure ingangsprocedure 

error fout 

error condition foutconditie 

error correction foutcorrectie 

error detection opsporen van fouten, foutsig- 
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nalering 

error message foutmelding 

error recovery foutherstel 

error routine foutroutine 

exception handling behandelen van een 
abnormale situatie 

Extended Core Storage (ECS) Uitgebreid 
Kernengeheugen 

external fragmentation externe fragmenta- 
tie 


fail-soft verminderde werking, sub-optimale 
werking 

failure storing 

failure recovery opheffen van een storing 

fatal error fatale fout 

feedback queue wachtrij met terugkoppe- 
ling 

feedback scheduler werkindeler met terug- 
koppeling 

fence address hekadres 

fence register hekregister 

fetch (to) ophalen 

fetch-only alleen-ophaalbaar 

file bestand 

file access method bestandstoegangsmethode 

file allocation toewijzing van bestandsruimte 

file directory bestandsadresboek 

file manipulation bestandsbewerking 

file operation bestandsbewerking 

file organization bestandsorganisatie 

file protection bestandsbeveiliging 

file structure bestandsstructuur 

file support bestandsondersteuning 

file system bestandssysteem 

File Transfer Protocol (FTP) protocol voor 
het overbrengen van bestanden, FTP 

First-Come-First-Served (FCFS) Wie-het- 
Eerst-Komt-het-Eerst-Maalt (WEKEM) 

first fit eerst-passend 

First-In-First-Out (FIFO) Eerst-In-Eerst- 
Uit, FIFO 

fixed-head disk schijf met vaste magneetkop- 
pen 

fixed partition vaste partitie 

floppy disk diskette, floppy 

foreground job voorgrond-job 

fork (operation) vertak(-bewerking) 

format (to) formateren 

formatting program formateerprogramma 

fragmentation (geheugen)fragmentatie 

frame (pagina)kader 
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frame allocation kadertoewijzing 

frame table kadertabel 

free frame list vrije-kaderlijst 

free space list vrije-ruimtelijst 

front end front-end(-machine) 

front end processor front-end-processor 

FTP (File Transfer Protocol) protocol voor 
het overbrengen van bestanden, FTP 

fully connected network volledig-verbonden 
netwerk 

function functie 


garbage collection sanering 

gateway poortverbinding, toegang tot net- 
werk, gateway 

general graph directory adresboek met alge- 
mene-graafstructuur 

graph graaf 

guarded command beschermd commando 


handshaking aansluitingsbevestiging 

hardware apparatuur 

hash function hash-functie 

hash tabel hash-tabel 

header aanhef, kop(gedeelte) 

higher-level programming language hogere 
programmeertaal 

hit ratio trefkans 

hold and wait bezet-houden-en-wachten 


identifier identificatiesymbool/ nummer 

idle zonder werk 

idle time leeglooptijd 

index index 

index block indexblok 

indexed allocation geïndiceerde toewijzing 

indexed sequential access method 
geïndiceerd-sequentiële toegangsmethode 

index file indexbestand 

index register indexregister 

indirect addressing indirecte adressering 

indivisible operation ondeelbare bewerking 

information hiding afschermen van informa- 
tie 

inode i(ndex)-knooppunt 

Input/Output (I/O) invoer/uitvoer, I/O 

instruction instructie 

interactive system interactief systeem 

interface koppeling, interface 

intermediate-level scheduling werkindeling 
op middellange termijn 

internal fragmentation interne (geheugen)- 
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fragmentatie 

interpreter vertolkingsprogramma, vertolker 

interprocess communication communicatie 
tussen processen 

interrupt onderbreking, interruptie, ingreep- 
signaal 

interrupt-driven door onderbrekingen ge- 
stuurd 

interrupt handler programma voor het afhan- 
delen van onderbrekingen 

interrupt service routine functieroutine voor 
het behandelen van onderbrekingen 

in use in gebruik 

invoke (to) aanroepen 

I/O (Input/Output) invoer/uitvoer, I/O 

I/O-bound door de I/O begrensd, 1/O-ge- 
bonden 

I/O burst 7/O-actie 

I/O control system I/O-besturingssysteem 

I/O device randapparaat 

I/O devices randapparatuur 

I/O overlap overlappende I/O 

I/O protection 1/O-beveiliging 

I/O queue 1/O-wachtrij 


JCL (Job Control Language) Job-besturings- 
taal, JCL 

job job, bewerking 

job control job-besturing 

Job Control Language (JCL) job-besturings- 
taal, JCL 

job queue wachtrij voor jobs, job-wachtrij 

job scheduler job-werkindelingsprogramma, 
job-werkindeler 

job scheduling job-werkindeling 

job scheduling algorithm algoritme voor 
job-werkindeling 

join (operation) verbind(-bewerking) 


language-based protection op taal gebaseer- 
de beveiliging 

language construct taalconstructie 

Large Core Storage (LCS) Groot Kernen- 
geheugen 

latency (schijf/trommel)-wachttijd 

layered approach gelaagde aanpak 

layered design gelaagd ontwerp 

layered file system bestandssysteem met 
meerdere lagen 

lazy swapper luie programmaverwisselaar 

Least-Recently-Used (LRU) Minst-Recent- 
Gebruikt (MRG) 


611 


library programmabibliotheek 

library programs bibliotheekprogramma’s 

library routines bibliotheekroutines 

limit register limietregister 

linear ordering lineaire ordening 

linear search lineaire zoekmethode 

line printer regeldrukker 

link schakel, verbinding(slijn) 

linkage editor montageprogramma 

linked allocation aaneengeschakelde toe- 
wijzing 

linked list aaneengeschakelde lijst 

load (to) laden 

load balancing in balans brengen van de 
werkbelasting 

loader laadprogramma, lader 

load module /aadmodule 

load sharing gemeenschappelijk dragen van 
de werkbelasting 

locality model lokaliteitsprincipe 

local replacement lokale paginavervanging 

lock (to) vergrendelen, blokkeren 

logical address logisch adres 

logical address space logische-adresruimte 

logical file system logisch-bestandssysteem 

logical I/O device logisch randapparaat 

logical memory logisch geheugen 

long-term scheduling werkindeling op lange 
termijn 

loosely coupled multiprocessing zwak-ge- 
koppelde multiverwerking 


magnetic head magneetkop 

mailbox brievenbus 

mainframe (computer) mainframe, universe- 
le computer 

main memory hoofdgeheugen, intern geheu- 
gen 

mass storage massageheugen 

master file hoofdbestand 

master file directory hoofdbestandsadres- 
boek 

master processor hoofdprocessor 

master/slave hoofdprocessor/bijprocessor, 
meester/slaaf 

master/slave design structure meester/ 
slaaf-ontwerpstructuur 

master/slave mode of operation meester/ 
slaaf-verwerkingswijze 

master/slave multiprocessor organization 
meester/slaaf-multiprocessororganisatie 

medium-term scheduling werkindeling op 
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middellange termijn 

memory (intern) geheugen 

memory fragmentation geheugenfragmenta- 
tie 

memory management geheugenbeheer 

memory protection geheugenbeveiliging 

memory reference geheugenverwijzing 

memory region geheugenregio 

memory space geheugenruimte 

menu-driven door menu's gestuurd 

message bericht 

message buffer berichtenbuffer 

message passing doorgeven van berichten 

message queue berichten-wachtrij 

message slot berichtenvak 

message switching doorschakelen van 
berichten 

message system berichtensysteem 

microcode microcode 

microcomputer micro(computer) 

microprocessor microprocessor 

minicomputer mini(computer) 

minidisk minischijfje 

mode werkwijze, modus 

modularization modulaire opbouw 

module module 

monitor monitor, toezichthoudend program- 
ma 

monitor call monitoraanroep 

monitor mode monitor-modus 

Most Frequently Used (MFU) Meest- 
Frequent-Gebruikt (MFG) 

moving-head disk schijf met bewegende mag- 
neetkoppen 

multi-access bus network netwerk met 
hoofdtransmissielijn en meervoudige toe- 
gang 

multi-level directory structure adresboek- 
structuur met meerdere niveaus 

multi-level feedback queue wachtrij met 
meerdere niveaus en terugkoppeling 

multi-level scheduling werkindeling met 
meerdere niveaus 

multiple partitions meerdere partities 

multiple processor scheduling werkindeling 
voor meer dan één processor 

multiprocessor voor/met meer dan één 
processor, multiprocessor 

multiprocessor system multiprocessor-sys- 
teem 

multiprogramming multiprogrammering 

multiprogramming level multiprogramme- 
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ringsniveau 
multi-volume tape file magneetbandbestand 
op meerdere volumes 
mutual exclusion wederzijdse uitsluiting 
mutual suspicion wederzijdse verdenking 


name space naamruimte 

nested monitor calls problem probleem van 
de geneste monitoraanroepen 

network netwerk 

non-preemptive zonder voortijdige onder- 
breking 

non-self-modifying code code die zichzelf 
niet wijzigt 

no-preemption geen voortijdige onderbre- 
king 


object file doelbestand, uitvoerbaar bestand 

object module doelmodule, werkmodule 

object program doelprogramma, werkpro- 
gramma 

off-line niet-gekoppeld 

offset relatieve positie (vanaf het begin) 

on-line gekoppeld 

open operation open-bewerking 

operating system besturingssysteem 

operating systemservice besturingssysteem- 
functie 

operation bewerking 

optimal replacement algorithm algoritme 
voor optimale paginavervanging 

optimization method methode voor optimali- 
sering 

overlapped I/O overlappende I/O 

overlay overlappend programmasegment, 
overlay 

overlay driver stuurroutine/programma voor 
overlays 

owner access right eigenaars toegangsrecht 

owner of a file eigenaar van een bestand 

ownership eigenaarschap, eigendomsrecht 


packet switching pakketschakeling 

page pagina 

page (to) pagineren 

paged segmentation gepagineerde segmen- 
tering 

page fault paginafout 

page fault frequency (PFF) paginafoutfre- 
quentie (PFF) 

page fault rate kans op paginafouten 

page fault routine paginafoutroutine 
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page frame (pagina)kader 

page frame table paginakadertabel 

page in (to) pagina's in het geheugen brengen 

page number paginanummer 

page out (to) pagina's uit het geheugen zetten 

page reference paginaverwijzing 

page reference string reeks paginaverwijzin- 
gen 

page replacement paginavervanging 

page replacement algorithm algoritme voor 
paginavervanging 

page size paginagrootte 

page swap(ping) pagina-uitwisseling 

page table paginatabel 

page table base register (PTBR) pagina- 
tabel-basis-register (PT BR) 

page table entry paginatabelingang 

page translation paginavertaling 

paging in pagina's verdelen, paginering 

paging device pagineerapparaat 

paper tape ponsband 

parameter passing doorgeven van parameters 

parbegin/parend statement parbegin/par- 
end-opdracht 

parity pariteit(s) 

partially connected network gedeeltelijk- 
verbonden netwerk 

partition (geheugen)partitie 

pass doorgang 

password wachtwoord 

path pad 

path name padnaam 

pause pauze 

PC (Personal Computer) computer voor per- 
soonlijk gebruik, PC 

performance prestatievermogen 

performance analysis prestatieonderzoek 

performance degradation verslechtering van 
het prestatievermogen 

performance evaluation prestatiebepaling 

peripheral device randapparaat 

Personal Computer (PC) computer voor per- 
soonlijk gebruik, PC 

physical fysiek 

physical address fysiek adres 

physical file system fysiek-bestandssysteem 

physical memory fysiek geheugen 

platter plaat 

plotter plotter, tekenmachine 

pointer wijzer 

polling navraag doen 

polling character navraagteken 


pool pot 

portability overdraagbaarheid 

preallocation toewijzing vooraf 

precedence voorrang 

precedence constraint voorrangsbeperking 

precedence graph voorrangsgraaf 

precedence relation voorrangsrelatie 

preempt (to) voortijdig onderbreken 

preemption voortijdige onderbreking 

preemptive met voortijdige onderbreking 

preemptive scheduling werkindeling met 
voortijdige onderbreking 

prepaging voorpagineren 

prevention of deadlock voorkómen van im- 
passes 

primary memory hoofdgeheugen, intern ge- 
heugen 

printer afdrukeenheid, printer 

priority prioriteit 

priority algorithm algoritme gebaseerd op 
prioriteit 

priority queue wachtrij met prioriteit 

priority scheduling werkindeling op basis van 
prioriteit 

privileged instruction bevoorrechte instructie 

procedure procedure 

process proces 

process communication communicatie tus- 
sen processen 

process concept begrip ‘proces’ 

process control block (PCB) procesbestu- 
ringsblok (PBB) 

process creation in het leven roepen van een 
proces 

process dispatching selectie van een proces 
voor verwerking 

process graph proces-graaf 

process hierarchy hiërarchie van processen 

process identifier procesnaam/nummer 

process initiation in het leven roepen van een 
proces 

process management procesbeheer 

process operation procesbewerking 

processor verwerkingseenheid, processor 

process priority prioriteit van een proces 

process state procestoestand 

process state diagram procestoestandsdia- 
gram 

process structure processtructuur 

process synchronization synchronisatie van 
processen 

process termination beëindiging van een pro- 
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ces 

producer/consumer problem producent/ 
consument-probleem 

program programma 

program counter programmateller 

programming programmering 

programming language programmeertaal 

proportional allocation evenredige toewij- 
zing 

protection beveiliging 

P synchronization operation P-synchronisa- 
tiebewerking 

punch ponsmachine 

pure code zuivere code, herbetreedbare code 

pure demand paging zuiver pagineren op ver- 
zoek 

pure paging zuiver pagineren 

pure segmentation zuiver segmenteren 


quantum of time tijd-quantum 
queue wachtrij 

queueing diagram wachtrij-diagram 
queueing model wachttijdenmodel 
queueing theory wachttijdtheorie 


raw interface primitieve koppeling 

read (to) lezen, inlezen 

readers/ writers problem lezers/schrijvers- 
probleem 

read-only alleen-uitlees(baar), read-only 

read/write head lees/schrijfkop 

ready queue gereed-wachtrij 

ready state gereed-toestand 

real-time onvertraagd 

real-time system onvertraagd systeem, Sys- 
teem met onvertraagde verwerking 

receive operation ontvang-bewerking 

reclaim (to) terugvorderen 

recovery herstel 

recovery from deadlock oplossen van een im- 
passe 

recovery from failure opheffen van een sto- 
ring 

redundancy redundantie 

reentrant herbetreedbaar, gelijktijdig bruik- 
baar 

reentrant code herbetreedbare code, zuivere 
code 

reference (pagina/geheugen)verwijzing 

reference bit referentiebit 

reference count aantal paginaverwijzingen 

reference string reeks paginaverwijzingen 
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region (geheugen)regio 

register register 

release (to) vrijgeven 

reliability betrouwbaarheid 

reload (to) opnieuw laden 

relocatable verplaatsbaar 

relocatable code verplaatsbare code 

relocatable loader verplaatsbaar laadpro- 
gramma 

relocation verplaatsing 

relocation register verplaatsingsregister 

remote op afstand 

Remote Job Entry (RJE) job-invoer op af- 
stand, RJE 

removable disk pack verwisselbaar schijven- 
pakket 

reposition (to) opnieuw positioneren 

request aanvraag, verzoek 

request block verzoekblok 

request queue verzoek-wachtrij 

reset (to) opnieuw instellen, terugstellen 

resource systeemelement, systeemfaciliteit 

resource allocation toewijzing van systeem- 
elementen 

resource allocation graph graaf voor het toe- 
wijzen van systeemelementen 

resource ordering ordening van systeemele- 
menten 

resource sharing gemeenschappelijk gebruik 
van systeemelementen 

response time responstijd 

restart (to) opnieuw starten 

restore (to) terugstellen, opnieuw instellen 

return (to) terugkeren, retourneren 

revocation of capabilities herroeping van be- 
schikkingsrechten 

ring network ringnetwerk 

RJE (Remote Job Entry) job-invoer op af- 
stand, RJE 

robustness robuustheid 

rollback terugkeer 

roll in/roll out uit het geheugen wegschrijven 
en opnieuw inlezen 

root directory worteladresboek 

rotational optimization rondgaande optima- 
lisering 

round robin met rondlopende wachtrij, bij 
toerbeurt 

round-robin scheduling werkindeling met 
rondlopende wachtrij, werkindeling bij 
toerbeurt 

run verwerking, run 
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run (to) a program een programma draaien 
running in uitvoering 
running state toestand van uitvoering 


safe state veilige toestand 

satellite processing satellietverwerking 

save (to) veilig stellen, veilig opbergen 

scan (to) aftasten 

scheduler werkindelingsprogramma, werkin- 
deler 

scheduling werkindeling 

scheduling algorithm algoritme voor werkin- 
deling 

scope geldigheidsgebied 

scope rules geldigheidsgebied-regels 

seal/unseal operation verzegel/ontsluit-be- 
werking 

secondary index secundaire index 

secondary storage hulpgeheugen, extern ge- 
heugen 

second chance replacement tweede-kans- 
vervanging 

sector queueing sector-wachtrijvorming 

security veiligheid(szekerheid) 

seek time zoektijd 

segment segment 

segmentation in segmenten verdelen, seg- 
mentering 

segmented paging gesegmenteerde pagine- 
ring 

segment fault segmentfout 

segment replacement segmentvervanging 

segment replacement algorithm algoritme 
voor segmentvervanging 

segment sharing gemeenschappelijk gebruik 
van segmenten 

segment size segmentgrootte 

segment table segmenttabel 

segment table base register (STBR) seg- 
menttabel-basis-register (STBR) 

segment table entry segmenttabelingang 

segment table length register (STLR) seg- 
menttabel-lengte-register (STLR) 

semaphore semafoor 

semiconductor memory halfgeleidergeheu- 

en 

da receive operation zend/ontvang-be- 
werking 

sequential access sequentiële toegang 

sequential file sequentieel bestand 

sequential process sequentieel proces 

service routine functieroutine 


set (to) zetten, instellen 

setup time opzettijd 

shared gemeenschappelijk gebruikt 

sharing gemeenschappelijk gebruik 

shell schil 

Shortest-Access-Time-First Kortste-Toe- 
gangstijd-Eerst 

Shortest-Job-First (SJF) Kortste-Job-Eerst 
(KJE) 

Shortest-Remaining-Time-First Kortste- 
Resterende-Tijd-Eerst 

Shortest-Seek-Time-First (SSTF) Kortste- 
Zoektijd-Eerst (KZE) 

short-term scheduling werkindeling op korte 
termijn 

signal synchronization operation signaal- 
synchronisatiebewerking 

simulation simulatie 

single-level directory adresboek met één ni- 
veau 

skip operation overslaan 

slave processor bijprocessor 

sleepy barber problem probleem van de 
slapende kapper 

software programmatuur 

software capability programmatuur-beschik- 
kingsrecht 

source file bronbestand 

source program bronprogramma 

space ruimte 

spooling spool-verwerking 

stack stapel 

staging trapsgewijze verwerking 

star network stervormig netwerk 

starvation verhongering 

state toestand 

statement opdracht 

static statisch 

status information statusinformatie 

storage geheugen, opslagruimte 

storage allocation geheugentoewijzing 

storage allocation method methode voor ge- 
heugentoewijzing 

storage compaction geheugencomprimering 

storage fragmentation geheugenfragmenta- 
tie 

storage hierarchy hiërarchie van geheugens 

store (to) opbergen, opslaan 

string rij tekens of bits, string 

subdirectory subadresboek 

subsystem subsysteem 

supervisor supervisieprogramma, supervisor 
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supervisor mode supervisie-modus 

suspended process proces waarvan de ver- 
werking is opgeschort 

swap (to) programmaverwisselen 

swap in (to) in het geheugen terugbrengen 

swap instruction programmaverwisselings- 
instructie 

swap out (to) uit het geheugen zetten 

swappable space ruimte waarin programma’s 
kunnen worden verwisseld 

swapping programmaverwisseling 

switch schakelaar, omschakeling 

switch time omschakelingstijd 

symbol table symbolentabel 

synchronization synchronisatie 

synchronization primitive elementaire syn- 
chronisatiefunctie 

synchronization problem synchronisatiepro- 
bleem 

synchronization scheme synchronisatieme- 
thode 

synchronization tool synchronisatiehulpmid- 
del 

synchronizing resources synchroniseren van 
systeemelementen 

system systeem 

system call systeemaanroep 

system design systeemontwerp 

system generation systeemgeneratie 

system implementation language taal voor 
systeemimplementatie 

system mode systeem-modus 


tape magneetband 

tape drive magneetbandaandrijfeenheid 

tape unit magneetbandeenheid 

task taak 

terminal terminal 

terminate (to) beéindigen 

terminate (to) a process een proces beéin- 
digen 

Test-and-Set instruction Test-en-Zet-in- 
structie 

thrashing ‘stampen’, doldraaien 

throughput doorvoercapaciteit 

tightly coupled multiprocessing sterk-gekop- 
pelde multiverwerking 

time-dependent error tijdafhankelijke fout 

timeout blokkeertijd, timeout 

time quantum tijd-guantum 

timer tijdregister 

time-sharing tijddeling 
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time-slice tijdschijfje 

time-stamp tijdregistratie 

timer interrupt onderbreking door het tijdre-. 
gister 

token merkteken 

token passing doorgeven van een merkteken 

trace detailverslag, trace 

trace tape detailverslag op magneetband 

transfer overbrenging 

transfer access right recht van overdracht 
van het toegangsrecht 

transfer time overbrengtijd 

trap ‘val’ 

trap handling afhandeling van een ‘val’ 

tree-structured directory adresboek met 
boomstructuur 

turnaround time turnaround-tijd 

two-level directory adresboek met twee ni- 
veaus 

two-pass assembler assembleerprogramma 
met twee doorgangen 


unbounded buffer onbegrensde buffer 

unidirectional communication link eenrich- 
tingscommunicatieverbinding 

uniform distribution uniforme verdeling 

uniprocessor voor/met één processor 

unsafe state onveilige toestand 

use gebruik 

user gebruiker 

user file gebruikersbestand 

user file directory gebruikersbestands- 
adresboek 

user mode gebruiker-modus 

user program gebruikersprogramma 

utility functieprogramma 


valid/invalid bit geldig/ongeldig-bit 

virtual virtueel 

virtual address virtueel adres 

virtual address space virtuele-adresruimte 

virtual memory virtueel geheugen 

virtual memory space virtuele-geheugen- 
ruimte 

Volume Table of Contents (VTOC) volume- 
inhoudsopgave, VTOC 

V synchronization operation V-synchroni- 
satiebewerking 

VTOC (Volume Table of Contents) volume 
inhoudsopgave, VTOC 

wait (to) wachten 

wait-for graph wacht-graaf 


WOORDENLIJST ENGELS-NEDERLANDS 


wait/signal wacht/sein 

wait synchronization operation wacht- 
synchronisatiebewerking 

wakeup operation wek-bewerking 

working set werkset 

working set model werkset-model 
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worst fit slechtst-passend 
write (to) (weg)schrijven 
write access right recht van schrijftoegang 


zero capacity nulcapaciteit 
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aandrijfeenheid drive 

aaneengeschakelde lijst linked list 

aaneengeschakelde toewijzing linked allo- 
cation 

aaneengesloten schijfruimte contiguous disk 
space 

aaneengesloten toewijzing contiguous allo- 
cation 

aanhef header 

aanroep call 

aanroepen call (to), invoke (to) 

aansluitingsbevestiging handshaking 

aantal paginaverwijzingen reference count 

aanvraag request 

abstract gegevenstype abstract data type 

(achteraan) toevoegen append (to) 

achtergrondgeheugen backing store, backup 
store 

achtergrond-job background job 

actief adresboek current directory 

acyclische graaf acyclic graph 

adres address 

adresbeveiliging address protection 

adresboek directory 

adresboekbestand directory file 

adresboekbestandssysteem directory file 
system 

adresboekingang directory entry 

adresboek met acyclische-graafstructuur 
acyclic graph directory 

adresboek met algemene-graafstructuur ge- 
neral graph directory 

adresboek met boomstructuur tree-struc- 
tured directory 

adresboek met één niveau single-level direc- 
tory 

adresboek met twee niveaus two-level direc- 
tory 

adresboekstructuur met meerdere niveaus 
multi-level directory structure 

adresboeksysteem directory system 

adresruimte address space 

adresseerfout addressing error 


adresseer-modus addressing mode 

adresseren address (to) 

adresvertaling address mapping, address 
translation 

afdrukeenheid printer 

afhandeling van een ’val’ trap handling 

afschermen van informatie information 
hiding 

aftasten scan (to) 

afwachten await (to) 

algoritme gebaseerd op prioriteit priority 
algorithm 

algoritme voor CVE-werkindeling CPU 
scheduling algorithm 

algoritme voor job-werkindeling job sched- 
uling algorithm 

algoritme voor optimale paginavervanging 
optimal replacement algorithm 

algoritme voor paginavervanging page re- 
placement algorithm 

algoritme voor segmentvervanging segment 
replacement algorithm 

algoritme voor werkindeling scheduling al- 
gorithm 

alleen-ophaalbaar fetch-only 

alleen-uitlees(baar) read-only 

apparatuur hardware 

array array 

assembleerprogramma assembler 

assembleerprogramma met twee doorgan- 
gen two-pass assembler 

assembleertaal assembly language 

associatief geheugen associative memory 

associatief register associative register 


bankiersalgoritme banker’s algorithm 
basisbestandssysteem basic file system 
basis- en limietregister base/limit registers 
basisregister base register 

batch-systeem batch system 
bedieningspaneel console 

beéindigen terminate (to) 

beéindiging van een proces process termina- 
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tion 

begrensde-bufferprobleem bounded-buffer 
problem 

begrip ‘proces’ process concept 

behandelen van een abnormale situatie ex- 
ception handling 

benaderen access (to) 

bericht message 

berichtenbuffer message buffer 

berichtensysteem message system 

berichtenvak message slot 

berichtenverkeer communication 

berichten-wachtrij message queue 

beschadiging crash 

beschermd commando guarded command 

beschikkingsrecht capability 

bestand file 

bestandsadresboek file directory 

bestandsbeveiliging file protection 

bestandsbewerking file manipulation, file 
operation 

bestandsondersteuning file support 

bestandsorganisatie file organization 

bestandsstructuur file structure 

bestandssysteem file system 

bestandssysteem met meerdere lagen /ay- 
ered file system 

bestandstoegangsmethode file access meth- 
od 

best-passend best fit 

besturingskaart control card 

besturingskaartvertolker control card inter- 
preter 

besturingssysteem operating system 

besturingssysteemfunctie operating system 
service 

betrouwbaarheid reliability 

beveiliging protection 

bevoorrechte instructie privileged instruc- 
tion 

bewerking job, operation 

bezet-houden-en-wachten hold and wait 

bezig busy 

bibliotheekprogramma’s library programs 

bibliotheekroutines library routines 

bijprocessor slave processor 

bij toerbeurt round robin 

binair binary 

binaire zoekmethode binary search 

bittabel bit map, bit table 

bitvector bit vector 

blok block 
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blokgrootte block size 

blokkeertijd timeout 

blokkeren lock (to) 

boekhouding accounting 

booleaanse boolean 

booleaanse expressie boolean expression 
booleaanse variabele boolean (variable) 
booleaanse voorwaarde boolean condition 
brievenbus mailbox 

bronbestand source file 

bronprogramma source program 
buffering buffering 
buffer-tussengeheugen buffer cache memory 
bus bus 


capaciteit capacity 

centrale verwerkingseenheid (CVE) Central 
Processing Unit, CPU, central processor 

cilinder cylinder 

circuitschakeling circuit switching 

code die zichzelf niet wijzigt non-self-modi- 
fring code 

coderen encript (to) 

commando command 

commandoregel command line 

commandotaal command language 

commandotaalvertolker command language 
interpreter 

commandovertolker command interpreter 

commando voor het bedieningspaneel con- 
sole command 

communicatie communication 

communicatielijn communication line 

communicatienetwerk communication net- 
work 

communicatieprocessor communication 
processor 

communicatiesysteem communication sys- 
tem 

communicatie tussen processen (inter)pro- 
cess communication 

communicatieverbinding communication 
link 

communicatieverbindingslijn communi- 
cation link 

communicatievoorziening communication 
facility 

compileerprogramma compiler 

comprimering compaction 

comprimering van gegevens data compac- 
tion 

computer voor persoonlijk gebruik (PC) 
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Personal Computer, PC 
concept construct 
conditievariabele condition variable 
constructie construct 
contextomschakeling context switch 
controlepunt checkpoint 
CVE (centrale verwerkingseenheid) Central 
Processing Unit, CPU, central processor 
CVE-actie CPU burst 
CVE-beveiliging CPU protection 
CVE-gebonden CPU-bound 
CVE-gebruiksfactor CPU utilization 
CVE-I/O-actiecyclus CPU-I/O-burst cycle 
CVE-reponstijd CPU response time 
CVE-turnaround-tijd CPU turnaround time 
CVE-wachttijd CPU waiting time 
CVE-werkindeling CPU scheduling 
cyclus cycle 


database data base 

default default 

detailverslag trace 

detailverslag op magneetband trace tape 

directe toegang direct access 

direct-toegankelijk bestand direct access file 

direct-toegankelijk geheugen direct access 
memory 

diskette floppy disk, diskette 

doelbestand object file 

doelmodule object module 

doelprogramma object program 

doldraaien thrashing 

domein domain 

doorbelasting accounting 

door de CVE begrensd CPU-bound 

door de I/O begrensd [/O-bound 

doorgang pass 

doorgeven van berichten message passing 

doorgeven van een merkteken token passing 

doorgeven van parameters parameter pass- 
ing 

door het systeem gekozen waarde default 

doorkiezen circuit switching 

door menu’s gestuurd menu-driven 

door onderbrekingen gestuurd interrupt- 
driven 

doorschakelen van berichten message 
switching 

doorvoercapaciteit throughput 

doorvoercapaciteit van de CVE CPU 
throughput 

dump dump 


WOORDENLIJST NEDERLANDS-ENGELS 


dynamische beveiliging dynamic protection 

dynamische geheugentoewijzing dynamic 
storage allocation 

dynamische verplaatsing dynamic relocation 

dynamisch laden dynamic loading 


een bestand (aan)maken create (to) a file 

een bestand opheffen delete (to) a file 

een proces beëindigen terminate (to) a 
process 

een proces in het leven roepen create (to) a 
process 

een programma draaien run (to) a program 

eenrichtingscommunicatieverbinding 
unidirectional communication link 

Eerst-In-Eerst-Uit First-In-First-Out 
(FIFO) 

eerst-passend first fit 

effectieve toegangstijd effective access time 

eigenaarschap ownership 

eigenaars toegangsrecht owner access right 

eigenaar van een bestand owner of a file 

eigendomsrecht ownership 

elegante degradatie elegant degradation 

elementaire synchronisatiefunctie synchro- 
nization primitive 

evenredige toewijzing proportional alloca- 
tion 

externe fragmentatie external fragmenta- 
tion 

extern geheugen backing store, backup store, 
secondary storage 


fatale fout fatal error 

FIFO First-In-First-Out (FIFO) 

financiéle administratie accounting 

floppy floppy disk, diskette 

formateerprogramma formatting program 

formateren format (to) 

fout error 

foutconditie error condition 

foutcorrectie error correction 

foutherstel error recovery 

foutmelding error message 

foutroutine error routine 

foutsignalering error detection 

fragmentatie (memory/storage) fragmen- 
tation 

front-end(-machine) front end 

front-end-processor front end processor 

FTP File Transfer Protocol, FTP 

functie function, capability 
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functieprogramma utility 

functieroutine service routine 

functieroutine voor het afhandelen van on- 
derbrekingen interrupt service routine 

fysiek physical 

fysiek adres physical address 

fysiek-bestandssysteem physical file system 

fysiek geheugen physical memory 

fysiek record block 


gateway gateway 

geblokkeerde toestand blocked state 

gebruik use 

gebruiker user 

gebruiker-modus user mode 

gebruikersbestand user file 

gebruikersbestandsadresboek user file di- 
rectory 

gebruikersprogramma user program 

gebruiksgemak convenience 

gebruik van buffers buffering 

gebruik van twee buffers double buffering 

gedeeltelijk-verbonden netwerk partially 
connected network 

gedistribueerd distributed 

gedistribueerd systeem distributed system 

geen voortijdige onderbreking no-preemp- 
tion 

gegeven(s) data 

gegevensbank data base 

gegevensverbindingslijn data link 

geheugen storage, memory 

geheugenafdruk dump 

geheugenbeheer memory management 

geheugenbeveiliging memory protection 

geheugencomprimering storage compaction 

geheugenfragmentatie (memory/ storage) 
fragmentation 

geheugenpartitie (memory) partition 

geheugenregio (memory) region 

geheugenruimte memory space 

geheugentoewijzing storage allocation 

geheugenverwijzing (memory) reference 

geïndiceerde toewijzing indexed allocation 

geindiceerd-sequentiéie toegangsmethode 
indexed sequential access method 

gekoppeld on-line 

gelaagde aanpak layered approach 

gelaagd ontwerp layered design 

geldigheidsgebied scope 

geldigheidsgebied-regels scope rules 

geldig/ongeldig-bit va/id/ invalid bit 
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gelijktijdig concurrent 

gelijktijdig bruikbaar reentrant 

gelijktijdigheid concurrency 

gelimiteerd wachten bounded waiting 

gemeenschappelijk dragen van de werkbelas- 
ting load sharing 

gemeenschappelijke routines common rou- 
tines 

gemeenschappelijk gebruik sharing 

gemeenschappelijk gebruikt shared 

gemeenschappelijk gebruik van segmenten 
segment sharing 

gemeenschappelijk gebruik van systeemele- 
menten resource sharing 

gepagineerde segmentering paged segmen- 
tation 

gereed-toestand ready state 

gereed-wachtrij ready queue 

gesegmenteerde paginering segmented 
paging 

gespreid distributed 

graaf graph 

graaf voor het toewijzen van systeemelemen- 
ten resource allocation graph 

graaf zonder lussen acyclic graph 

grensregisters bounds registers 

groep batch 

groepsgewijze verwerking batch processing 

Groot Kernengeheugen Large Core Storage 
(LCS) 


halfgeleidergeheugen semiconductor mem- 


er 

hash-functie hash function 

hash-tabel hash tabel 

hekadres fence address 

hekregister fence register 

herbetreedbaar reentrant 

herbetreedbare code pure code, reentrant 
code 

herroeping van beschikkingsrechten revoca- 
tion of capabilities 

herstel recovery 

hiërarchie van geheugens storage hierarchy 

hiërarchie van processen process hierarchy 

hogere programmeertaal higher-level pro- 
gramming language 

hoofdbestand master file 

hoofdbestandsadresboek master file direc- 
tory 

hoofdgeheugen main memory, primary 
memory 
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hoofdprocessor master 
hoofdprocessor/bijprocessor master/slave 
hoofdtransmissielijn bus 

hulpgeheugen secondary storage 


identificatiesymbool/nummer identifier 

i-knooppunt inode 

impasse deadlock, deadly embrace 

in balans brengen van de werkbelasting load 
balancing 

indeling in blokken blocking 

in de lucht hangende wijzer dangling pointer 

index index 

indexbestand index file 

indexblok index block 

index-knooppunt inode 

indexregister index register 

indirecte adressering indirect addressing 

ingang entry 

ingangsprocedure entry procedure 

in gebruik busy, in use 

ingreepsignaal interrupt 

in het geheugen terugbrengen swap in (to) 

in het leven roepen van een proces process 
creation, process initiation 

inlezen read (to) 

in pagina’s verdelen paging 

in segmenten verdelen segmentation 

instellen set (to) 

instructie instruction 

interactief systeem interactive system 

interface interface 

interne (geheugen)fragmentatie internal 
fragmentation 

intern geheugen (main/primary) memory 

interruptie interrupt 

in uitvoering running 

invoer/uitvoer Input/Output, I/O 

I/O Input/Output, I/O 

I/O-actie I/O burst 

I/O-besturingssysteem J/O control system 

I/O-beveiliging 7/0 protection 

I/O-gebonden [/O-bound 

I/O-wachtrij I/O queue 


JCL Job Control Language, JCL 

job job 

job-besturing job control 

job-besturingstaal Job Control Language, 
JCL 

job-invoer op afstand Remote Job Entry, 
RJE 
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job-wachtrij job queue 

job-werkindeler job scheduler 
job-werkindeling job scheduling 
job-werkindelingsprogramma job scheduler 


kaartbeeld card image 

kaartlezer card reader 

kader (page) frame 

kadertabel frame table 

kadertoewijzing frame allocation 

kale machine bare machine 

kanaal channel 

kanaalprogramma channel program 

kans op paginafouten page fault rate 

kop(gedeelte) header 

koppelen bind (to) 

koppeling interface 

Kortste-Job-Eerst (KJE) Shortest-Job-First 
(SJF) 

Kortste-Resterende-Tijd-Eerst Shortest- 
Remaining-Time-First 

Kortste-Toegangstijd-Eerst Shortest- 
Access-Time-First 

Kortste-Zoektijd-Eerst (KZE) Shortest- 
Seek-Time-First (SSTF) 

kritieke regio critical region 

kritieke sectie critical section 


laadmodule load module 

laadprogramma loader 

laden load (to) 

lader loader 

leeglooptijd idle time 

lees/schrijfkop disk head, read/ write head 

lezen read (to) 

lezers/schrijversprobleem readers/writers 
problem 

limietregister limit register 

lineaire ordening linear ordering 

lineaire zoekmethode linear search 

logisch adres logical address 

logisch-bestandssysteem logical file system 

logische-adresruimte logical address space 

logisch geheugen logical memory 

logisch randapparaat logical I/O device 

lokale paginavervanging local replacement 

lokaliteitsprincipe locality model 

lopend adresboek current directory 

luie programmaverwisselaar lazy swapper 

lus cycle 


magneetband tape 
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magneetbandaandrijfeenheid tape drive 

magneetbandbestand op meerdere volumes 
multi-volume tape file 

magneetbandeenheid tape unit 

magneetkop magnetic head 

mainframe mainframe (computer) 

massageheugen mass storage 

meerdere partities multiple partitions 

meester/slaaf master/ slave 

meester /slaaf-multiprocessor-organisatie 
master! slave multiprocessor organization 

meester /slaaf-ontwerpstructuur master/ 
slave design structure 

meester /slaaf-verwerkingswijze master/ 
slave mode of operation 

Meest-Frequent-Gebruikt (MFG) Most 
Frequently Used (MFU) 

merkteken token 

met dubbele dichtheid double-density 

methode voor geheugentoewijzing storage 
allocation method 

methode voor optimalisering optimization 
method 

met rondlopende wachtrij round robin 

met voortijdige onderbreking preemptive 

microcode microcode 

micro(computer) microcomputer 

microprocessor microprocessor 

minicomputer) minicomputer 

minischijfje minidisk 

Minst-Recent-Gebruikt (MRG) Least- 
Recently-Used (LRU) 

modulaire opbouw modularization 

module module 

modus mode 

monitor monitor 

monitoraanroep monitor call 

monitor-modus monitor mode 

montageprogramma linkage editor 

multiprocessor multiprocessor 

multiprocessor-systeem multiprocessor sys- 
tem 

multiprogrammering multiprogramming 

multiprogrammeringsniveau multiprogram- 
ming level, degree of multiprogramming 

mutatiebit dirty bit 


naamruimte name space 

navraag doen polling 

navraagteken polling character 

netwerk network 

netwerk met hoofdtransmissielijn en meer- 
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voudige toegang multi-access bus network 
netwerk met sterverbinding connected star 
network 
niet-gekoppeld off-line 
nulcapaciteit zero capacity 


omschakeling switch 

omschakelingstijd switch time 
onbegrensde buffer unbounded buffer 
ondeelbare bewerking indivisible operation 
onderbreking interrupt 

onderbreking door een randapparaat device 


interrupt 
onderbreking door het tijdregister timer in- 
terrupt 


ontdekken van botsingen collision detection 

ontvang-bewerking receive operation 

onveilige toestand unsafe state 

onvertraagd real-time 

onvertraagd systeem real-time system 

op afstand remote 

opbergen store (to) 

opdracht command, statement 

open-bewerking open operation 

ophalen fetch (to) 

opheffen van een storing failure recovery, re- 
covery from failure 

oplossen van een impasse deadlock recovery, 
recovery from deadlock 

opnieuw instellen reset (to), restore (to) 

opnieuw laden reload (to) 

opnieuw positioneren reposition (to) 

opnieuw starten restart (to) 

opslaan store (to) 

opslagruimte storage 

opsporen van een impasse deadlock detec- 
tion 

opsporen van een lus cycle detection 

opsporen van fouten error detection 

op taal gebaseerde beveiliging language- 
based protection 

opzettijd setup time 

ordening van systeemelementen resource or- 
dering 

overbrenging transfer 

overbrengtijd transfer time 

overdraagbaarheid portability 

overdrachtsbit carry bit 

overlappende I/O 7/0 overlap, overlapped 
I/O 

overlappend programmasegment overlay 

overlay overlay 
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overschakelen op een ander domein domain 
switching 
overslaan skip operation 


pad path 

padnaam path name 

pagina page 

paginafout page fault 

paginafoutfrequentie (PFF) page fault 
frequency (PFF) 

paginafoutroutine page fault routine 

paginagrootte page size 

paginakader (page) frame 

paginakadertabel page frame table 

paginanummer page number 

pagina’s in het geheugen brengen page in 
(to) 

pagina’s uit het geheugen zetten page out (to) 

paginatabel page table 

paginatabel-basis-register (PTBR) page 
table base register (PTBR) 

paginatabelingang page table entry 

pagina-uitwisseling page swap(ping) 

paginavertaling page translation 

paginavervanging page replacement 

paginaverwijzing (page) reference 

pagineerapparaat paging device 

pagineren page (to) 

pagineren op verzoek demand paging 

paginering, paging 

pakketschakeling packet switching 

parallel concurrent 

parallelle processen concurrent processes 

parallellisme concurrency 

parallel-opdracht concurrent statement 

parallel-programmeertaal concurrent lan- 
guage 

parallel-programmeertaal concurrent pro- 
gramming language 

parallel-programmering concurrent pro- 
gramming 

parallelverwerking concurrency 

parbegin/parend-opdracht parbegin/parend 
statement 

pariteit(s) parity 

partitie (memory) partition 

pauze pause 

PC Personal Computer, PC 

platter plaat 

plotter plotter 

ponsband paper tape 

ponsmachine punch 
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poortverbinding gateway 

pot pool 

prestatiebepaling performance evaluation 

prestatieonderzoek performance analysis 

prestatievermogen performance 

primitieve koppeling raw interface 

printer printer 

prioriteit priority 

prioriteit van een proces process priority 

probleem van de geneste monitoraanroepen 
nested monitor calls problem 

probleem van de slapende kapper sleepy bar- 
ber problem 

probleem van de tafelende filosofen dining 
philosophers problem 

procedure procedure 

proces process 

procesbeheer process management 

procesbesturingsblok (PBB) process control 
block (PCB) 

procesbewerking process operation 

proces-graaf process graph 

procesnaam/nummer process identifier 

processor processor 

processtructuur process structure 

procestoestand process state 

procestoestandsdiagram process state dia- 
gram 

proces waarvan de verwerking is opgeschort 
suspended process 

producent/consumentprobleem producer / 
consumer problem 

programma program 

programmabibliotheek library 

programmateller program counter 

programmatuur software 

programmatuur-beschikkingsrecht software 
capability 

programmaverwisselen swap (to) 

programmaverwisseling swapping 

programmaverwisselingsinstructie swap in- 
struction 

programma voor het afhandelen van onder- 
brekingen interrupt handler 

programmeertaal programming language 

programmering programming 

protocol voor het overbrengen van bestan- 
den File Transfer Protocol (FTP) 

P-synchronisatiebewerking P synchroniza- 
tion operation 


randapparaat (I/O) device, peripheral device 
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randapparaatadresboek device directory 

randapparaat-onafhankelijkheid device in- 
dependence 

randapparaat-status device status 

randapparaat-statustabel device status table 

randapparaat-wachtrij device queue 

randapparatuur //O devices 

randapparatuurbeheer device management 

read-only read-only 

recht van kopiëren van het toegangsrecht 
copy access right 

recht van overdracht van het toegangsrecht 
transfer access right 

recht van regulatie van het toegangsrecht 
control access right 

recht van schrijftoegang write access right 

redundantie redundancy 

reeks array 

reeks paginaverwijzingen (page) reference 
string 

referentiebit reference bit 

regeldrukker line printer 

register register 

relatieve positie (vanaf het begin) offset 

reservegeheugen backing store, backup store 

reservekopie backup copy 

responstijd response time 

resultaatcode condition code 

retourneren return (to) 

rij tekens of bits string 

ringnetwerk ring network 

RJE Remote Job Entry, RJE 

robuustheid robustness 

romp(code) body 

rondgaande optimalisering rotational opti- 
mization 

rondlopende wachtrij circular queue 

ruimte space 

ruimte waarin programma’s kunnen worden 
verwisseld swappable space 

run run 


samenwerkende sequentiéle processen 
cooperating sequential processes 

sanering garbage collection 

satellietverwerking satellite processing 

schakel link 

schakelaar switch 

schijf disk 

schijfaandrijfeenheid disk drive 

schijfeenheid disk unit 

schijf met bewegende magneetkoppen 
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moving-head disk 

schijf met vaste magneetkoppen fixed-hea 
disk : 

schijfruimte disk space 

schijfwachttijd latency 

schijf-werkindeling disk scheduling 

schijvengeheugen disk 

schijvenpakket disk pack 

schil shell 

schrijven write (to) 

sector-wachtrijvorming sector queueing 

secundaire index secondary index 

segment segment 

segmenteren op verzoek demand segmen- 
tation 

segmentering segmentation 

segmentfout segment fault 

segmentgrootte segment size 

segmenttabel segment table 

segmenttabel-basis-register (STBR) seg- 
ment table base register (STBR) 

segmenttabelingang segment table entry 

segmenttabel-lengte-register (STLR) seg- 
ment table length register (STLR) 

segmentvervanging segment replacement 

selectie van een proces voor verwerking 
process dispatching 

selectie voor verwerking dispatching 

semafoor semaphore 

sequentieel bestand sequential file 

sequentieel proces sequential process 

sequentiéle toegang sequential access 

signaal-synchronisatiebewerking signal 
synchronization operation 

simulatie simulation 

simultaan concurrent 

simultane verwerking concurrency 

slechtst-passend worst fit 

sluiten close (to) 

spool-verwerking spooling 

‘stampen’ thrashing 

stapel stack 

statisch static 

statusinformatie status information 

sterk-gekoppelde multiverwerking tightly 
coupled multiprocessing 

stervormig netwerk star network 

storing failure 

string string 

stuurroutine/programma driver 

stuurroutine/ programma voor overlays 
overlay driver 


stuurroutine/ programma voor randappara- 
tuur device driver 

subadresboek subdirectory 

sub-optimale werking fail-soft 

subsysteem subsystem 

supervisie-modus supervisor mode 

supervisieprogramma supervisor 

supervisor supervisor 

symbolentabel symbol table 

synchronisatie synchronization 

synchronisatiehulpmiddel synchronization 
tool 

synchronisatiemethode synchronization 
scheme 

synchronisatieprobleem synchronization 

_ problem 

synchronisatie van processen process 
synchronization 

synchroniseren van systeemelementen 
synchronizing resources 

systeem system 

systeemaanroep system call 

systeemelement resource 

systeemfaciliteit resource 

systeemgeneratie system generation 

systeem met onvertraagde verwerking real- 
time system 

systeem-modus system mode 

systeemontwerp system design 

systeemstoring crash 

systeem voor berichtenverkeer communica- 
tion message system 

systeem voor groepsgewijze verwerking 
batch system 


taak task 

taalconstructie language construct 

taal voor systeemimplementatie system im- 
plementation language 

tekenmachine plotter 

tekstopmaak editing 

tekstopmaakprogramma editor 

teller counter 

terminal terminal 

terugkeer rollback 

terugkeren return (to) 

terugstellen reset (to), restore (to) 

terugvorderen reclaim (to) 

Test-en-Zet-instructie Test-and-Set instruc- 
tion 

tijdafhankelijke fout time-dependent error 

tijddeling time-sharing 
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tijd-quantum quantum of time, time quantum 

tijdregister timer 

tijdregistratie time-stamp 

tijdschijfje time-slice 

timeout timeout 

toegang access 

toegangsbesturing access control 

toegangsmatrix access matrix 

toegangsmethode access method 

toegangsrecht access right 

toegangsrecht-expressie access right expres- 
sion 

toegangsregulatie access control 

toegang tot netwerk gateway 

toepassing application 

toepassingsprogramma application program 

toestand state 

toestand van uitvoering running state 

toewijzing allocation 

toewijzingsmethode allocation method 

toewijzing van bestandsruimte file allocation 

toewijzing van schijfruimte disk space allo- 
cation 

toewijzing van systeemelementen resource 
allocation 

toewijzing vooraf preallocation 

toezichthoudend programma monitor 

trace trace 

trapsgewijze verwerking staging 

trefkans hit ratio 

trommel(geheugen) drum 

trommelwachttijd latency 

turnaround-tijd turnaround time 

tussengeheugen cache memory 

tweede-kans-vervanging second chance re- 
placement 

tweeweg-communicatieverbinding bidirec- 
tional communication link 


uitbreiding amplification 

Uitgebreid Kernengeheugen Extended Core 
Storage (ECS) 

uit het geheugen wegschrijven en opnieuw 
inlezen roll in/roll out 

uit het geheugen zetten swap out (to) 

uitvoerbaar bestand object file 

uniforme verdeling uniform distribution 

universele computer mainframe (computer) 


‘val’ trap 
vaste partitie fixed partition 
veilige toestand safe state 
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veiligheid(szekerheid) security 

veilig opbergen save (to) 

veilig stellen save (to) 

verbind(-bewerking) join (operation) 

verbinding(slijn) link 

verbindingsstrategie connection strategy 

verdeelprogramma dispatcher 
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In dit boek gever de auteurs een analyse van de 

fundamentele begrippen die ten grondslag liggen aan 

besturingssystemen. Daarbij concentreren zij zich niet 

op enkele bestaande systemen, maar geven een heldere kijk 

op de evolutie van een kale machine met residente monitor 

tot gedistribueerde systemen en Unix. De nadruk ligt op 

de grote verscheidenheid aan oplossingen voor problemen 

en beperkingen, onder meer opgelegd door de apparatuur, 

of dit nu mainframes zijn of mini- en microcomputers. 

De lezer ziet hoe de diverse oplossingen in bestaande 

(of vroegere) systemen zijn toegepast. 

Behandeld worden: 

— besturingssystemen 

— bestandssystemen 

— de klassieke interne algoritmen en structuren van 
besturingssystemen: CVE -werkindeling, geheugenbeheer, 
beheer randapparatuur, impasses (deadlocks) 

— het formele procesmodel 

— het computersysteem als verzameling van samenwerkende 
sequentiële processen 

— geavanceerde onderwerpen en trends: 
hogere programmeertalen voor parallel-programmering, 
beveiligingssystemen, ontwerpprincipes, gedistribueerde 
systemen, Unix 

Het onderwerp wordt zeer grondig en desondanks niet 

‘moeilijk’ behandeld. Behalve door de duidelijke tekst wordt 

de student/ lezer geholpen door talrijke voorbeelden, 

tekeningen, literatuurverwijzingen en meer dan 200 opgaven. 
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